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I.  INTRODUCTION 

A.  BACKGROUND 

Because  of  their  low  cost  relative  to  client  server  and  mainframe  applications, 
Intranets  have  gained  popularity  in  business  operations  worldwide.  Additional  factors 
that  have  supported  the  increased  popularity  are  their  ease  of  use  and  the  ability  to  rapidly 
deploy  information  and  applications  enterprise  wide. 

Intranets  developed  out  of  the  popularity  of  the  Internet  and  the  World  Wide 
Web1  (WWW).  The  Internet  was  developed  by  the  Defense  Advanced  Research  Projects 
Agency  (DARPA)  and  the  National  Science  Foundation  (NSF)  as  a  means  to  connect 
national  command  and  control  computers  and  networks  in  a  manner  that  would  survive 
nuclear  attack  directed  against  the  United  States.  The  World  Wide  Web  is  just  an 
extension  of  the  Global  Internet. 

B.  THE  INTERNET 

The  entire  Internet  is  global  and  involves  many  different  protocols  and 
communications  schemes.  The  World  Wide  Web  (WWW)  is  a  subset  of  the  Internet  that 
has  experienced  explosive  growth  since  1990.  WWW  technology  is  centered  on  the 
Transmission  Control  Protocol/Internet  Protocol  (TCP/IP).  Use  of  TCP/IP  and  browser 
software  allows  users  to  have  a  graphical  interface  to  other  computers  and  networks  also 
using  TCP/IP  and  WWW  based  servers. 

The  ease  of  use,  which  is  the  primary  reason  for  the  popularity  of  the  WWW,  is 
supported  primarily  by  the  intuitive  nature  of  the  graphical  interface.    The  interface  is 


known  as  hypertext2.  The  concept  of  hypertext  involves  attaching  links  to  selected  words 
or  images  to  point  to  related  information.  Users  can  select  highlighted  words,  phrases  or 
images  and  quickly  navigate  to  related  WWW  sites  or  related  information  elsewhere  in 
that  file  or  resource. 

C.  INTRANETS 

There  are  many  definitions  of  Intranets.  Some  researchers  define  Intranets  as 
containing  some  form  of  proprietary  or  enterprise  specific  applications  and 
communications  protocols.  Others  use  a  more  broad  definition,  "a  non-public  website 
devoted  to  one  company  and  for  one  company".3 

Basically  an  Intranet  is  a  collection  of  technologies  that  are  common  to  the 
Internet  to  publish  and  share  information  within  an  organization  amongst  organization 
employees  rather  than  sharing  or  providing  information  to  the  general  public.  Developing 
and  deploying  Internet  technologies  that  use  the  previously  discussed  hypertext  WWW 
tools  for  internal  publishing  solves  both  technical  issues  and  practical  problems  of 
information  currency  and  availability.4 

In  order  to  have  value  the  Intranet  needs  to  support  some  organizational  function. 
Since  Intranets  are  "non-public"  the  value  is  not  derived  from  revenue  generation  but 
from  supporting  management  or  business  functions.    Possible  business  functions  are; 

1  Rizzo,  John,  "Intranet  101",  Bay  Area  Computer  Currents,  February  4  1997,  pp45-58 

2  Levitt,  Lee,  "Intranets:  Internet  Technologies  Deployed  Behind  the  Firewall  for 
Corporate  Productivity",  prepared  for  Internet  Society  INET'96  Annual  Meeting 

3  According  to  Adam  Kuhn,  of  Edison  Electric  Institute,  quoted  in  "Finding  the  right 
Intranet  Technologies  to  buy",  Strom,  David,  6/10/96, 
http://www.strom.com/pubwork/intranet.html 

4  http://www.zdnet.com/intweek/print/951 1 13/webguide/docl. html 


decision  making,  information  sharing,  information  gathering,  policy  and  news  publishing 
and  group  collaboration.  Because  Intranets  are  not  revenue  generators,  managers  must 
understand  the  associated  benefits  and  limitations  of  Intranets. 

1.    Benefits  of  Intranets 

There  are  several  main  benefits  that  Internet  technologies  bring  to  organizations. 
These  include  the  ease  of  sharing  information  between  connected,  computers,  the  ability 
to  develop  applications  that  support  the  prevalence  of  heterogeneous  (varying  operating 
systems  and  hardware  architectures)  computers  throughout  organizations,  common  user 
application  interfaces,  and  e-mail  and  browsers5.  The  attractiveness  of  Intranets  over 
groupware,  client-server  applications,  and  proprietary  applications  is  that  Intranets  can 
accomplish  these  functions  at  a  lower  cost. 

Rapid  prototyping,  ease  of  setup,  scalability,  and  availability  of  tools  are  the  key 
features  that  make  Intranets  economical  and  attractive  to  organizations.  These  four 
characteristics  combine  to  enable  the  services  and  protocols  that  are  used  to  build  and 
deploy  the  Intranet  system,  which  in  turn  supports  the  functions  of  the  organization. 

Using  the  enterprise  Intranet  as  a  means  for  information  sharing  can  have  some 
cost  savings  and  therefore  some  monetary  value  to  an  organization.  Navigation  through 
hypertext  links  and  information  retrieval  is  relatively  simple,  which  will  keep  training 
costs  down.6  Internet  and  Intranet  information  publishing  is  accomplished  with  HTML 
pages  that  are  generally  restricted  to  presenting  static  information.      New  tools  and 


5  Levitt,  Lee,  "Intranets:  Internet  Technologies  Deployed  Behind  the  Firewall  for 
Corporate  Productivity",  prepared  for  Internet  Society  INET'96  Annual  Meeting 

6  Ibid 


techniques  are  making  dynamic  publishing  possible.  (The  information  in  this  prototype 
is  not  restricted  to  static  text  or  graphics.) 

As  stated  cost  savings  can  account  for  some  monetary  benefit  of  an  Intranet. 
Publishing  dynamic  information  via  the  Intranet  allows  information  to  be  shared  through 
automated  presentation  of  routine  reports  and  messages,  and  decreased  decision  timelines 
through  access  to  current,  dynamically  updated  information.  Intranet  based  information 
sharing  also  will  decrease  expenditures  for  the  raw  materials  (for  example,  paper  and 
copier  toner)  for  traditional  printed  distribution.  Additional  savings  will  be  seen  in  labor 
and  maintenance  costs.  Fewer  paper  copies  will  be  needed,  resulting  in  lower  copier 
usage,  so  copier  maintenance  costs  will  decrease.  Finally,  clerical  personnel  will  not  be 
required  to  make  and  distribute  multiple  copies. 

Some  additional  benefits  of  Intranets  include  things  like  marketing  value  and  the 
opportunity  to  forge  new  business  relationships  with  customers,  such  as  the  ability  to 
attract  quality  candidates,  and  the  opportunity  to  create  a  sense  of  community.8 

In  the  context  of  the  Prototype  developed  for  this  thesis  and  the  purpose  of  this 
research,  one  of  the  primary  values  of  Intranets  is  the  way  in  which  Intranets  support 
information  sharing.  The  information  sharing  can  be  in  many  forms.  Information  can  be 
published  to  a  central  site  for  all  personnel  to  view,  similar  to  bulletin  boards. 
Information  can  be  stored  in  databases  for  retrieval  as  needed  by  users.  Intranets  can  be 
used  to  collect  information  from  throughout  the  organization  for  use  by  a  centralized  or 


Currid,  Cheryl,  "Quit  Stalling  and  Start  an  Intranet",  Windows  Magazine,  p.49,  April 
1997 
8  Slater,  Derek,  WebMaster  Magazine,  CIO  Publications  Inc  -  April  1 997 


traditional  application.  And  finally  Intranets  can  gather  information  and  allow  users  to 
have  dynamic  access  to  the  information  from  any  location  on  the  enterprise  network. 

2.    Limitations 

The  key  limitations  of  Intranets  are  how  cost  and  benefit  are  assigned  to  the 
Intranet  development  and  support.  Assigning  a  value  to  the  function  of  information 
sharing  is  difficult.  Intranets  do  not  make  this  value  determination  any  easier.  Managers 
are  still  faced  with  answering  the  question  of  "what  is  the  information  worth  to  me,  and 
how  much  am  I  willing  to  pay  to  get  the  information?"  Intranets  also  add  the  question  of 
"how  does  this  use  of  technology  allow  me  to  make' better  decisions  or  make  decisions 
better?" 

Cost  savings  and  traditional  return  on  investment  (ROI)  calculations  are  risky. 
The  very  nature  of  the  Intranet  being  internal  and  not  contributing  to  revenue  generation 
is  obvious.  Skeptics  will  also  point  out  that  the  cost  savings  for  paper  and  toner  will  be 
negligible  and  users  will  probably  print  out  and  store  or  discard  as  much  as  was 
previously  distributed.  There  are  many  drawbacks  of  traditional  ROI  thinking.  "There's 
something  about  that  reach  and  the  value  Intranets  create  that  just  isn't  captured  by 
traditional  ways  of  looking  at  ROI."9 

Critics  of  Intranets  also  point  out  that  one  impact  of  relying  on  automated 
information  exchange  versus  more  traditional  paper  methods  is  the  lack  of  personal  face 
to  face  interaction  of  workers.  To  minimize  the  risk  to  interaction,  Intranets  should  be 
used  to  alleviate  some  of  the  information  bottlenecks,  increase  information  availability, 
and  reduce  information  search  times  within  organizations  so  that  workers  time  can  be 


spent  making  decisions  and  increase  the  actual  amount  of  time  available  for  work  and 
interaction. 

There  are  also  some  technological  limitations  of  Intranets.  Due  to  the  nature  of 
HTML  publishing  many  complex  queries  cannot  be  handled  which  requires  that 
developers  break  the  problem  into  sequential  steps.  This  means  that  the  developers  must 
conduct  a  thorough  analysis  of  the  process  or  system  being  automated.  Care  must  also  be 
exercised  when  developing  the  interface  so  that  the  users  are  provided  appropriate 
feedback  and  that  information  retrieval  is  as  efficient  as  possible. 

D.  DECISION  SUPPORT  SYSTEMS 

DSS  are  systems  developed  to  assist  managers  with  decision  problems.  DSS  vary 
in  the  way  they  perform.  Some  DSS  function  by  using  mathematical  modeling,  others 
perform  simulations  and  others  facilitate  negotiation  and  collaboration.  Sophisticated 
DSS  perform  combinations  of  these  functions. 

DSS  which  support  mathematical  modeling,  help  the  manage/user  develop  an 
optimal  or  best  solution.  These  models  can  offer  the  user  either  a  range  of  acceptable 
solutions,  where  one  optimal  solution  cannot  be  efficiently  determined  or  the  tools  can  be 
used  for  modeling  to  show  the  user  the  consequences  of  management  decisions. 

DSS  which  support  simulations,  allow  the  decision-maker  to  run  scenarios  to  test 
the  impact  of  changes  in  different  variables  on  the  independent  decision  variable.  The 
benefit  of  simulation  DSS  is  that  they  allow  the  user  to  compress  time  or  run  multiple 
simulations  at  low  cost. 


Slater,  Derek,  WebMaster  Magazine,  CIO  Publications  Inc.-  April  1997 
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No  matter  the  function,  the  DSS  can  be  of  many  types.  There  are  stand  alone 
DSS  that  support  a  single  user,  network  DSS  that  support  multiple  users  making 
individual  decisions,  and  group  DSS  that  are  designed  specifically  to  support 
collaboration  and  the  dynamics  of  groups. 

For  the  purpose  of  this  research  DSS  are  defined  in  a  much  broader  manner. 
DSS  are  defined  as  any  tool  that  supports  the  user  in  formulating  or  making  management 
decisions.  This  broad  definition  includes  the  mathematical  processes  of  decision 
optimization  and,  for  the  Intranet  Prototype,  includes  decision  support  functions  such  as 
information  sharing,  information  retrieval  and  group  collaboration. 

Traditional  decision  making  often  results  in  a  sub-optimal  solution,  usually 
because  the  decision  did  not  have  the  time  to  search  for  all  the  relevant  information  or  the 
cost  of  keeping  all  the  information  available  for  immediate  use  has  been  prohibitive. 
Allowing  the  decision-maker  access  to  enterprise,  or  even  global,  information  resources 
in  a  timely  and  efficient  manner  will  allow  the  decision-maker  to  make  a  more  informed 
and  therefore  better  decision. 

E.  DECISION  SUPPORT  USING  THE  WWW 

There  are  many  examples  of  Internet  based  DSS's.  Some  examples  of  Internet 
based  decision  can  be  found  at  http://dnet.as.nps.navy.mil  (DecisionNet), 
http://www.mcs.anl.gov     (NEOS),     http://www.olsonresearch.com     (Olson     Research 


Associates,  and  http://weber.ii. washington.edu/~cyj/tsp/tspnew.html  (Sensitivity  Analysis 
for  the  Euclidean  Traveling  Salesman  Problem).10 

DecisionNet  is  a  particularly  applicable  location  because  the  DecisionNet  is  a 
Project  that  is  "a  distributed  collection  of  decision  technologies  that  are  accessible  and 
executable  over  the  World  Wide  Web"11 

The  NEOS  (Network  Enabled  Optimization  System)  is  a  site  that  allows  users  to 
access  computational  resources  remotely.  Olson  Research  Associates  is  a  consulting  firm 
that  specializes  in  financial  depository  institutions. 

The  concept  that  any  computer  can  retrieve  information  with  a  WWW  browser  is 
known  as  platform  independence.  If  the  access  permissions  are  set  to  allow  access, 
faculty  members  will  have  access  to  the  same  information  while  traveling,  at  home  or 
down  the  hall,  that  they  have  while  at  their  own  desk.  Platform  independence  includes 
the  concept  of  multiple  hardware  designs  and  architectures.  (For  example,  Apple 
Macintosh,  Unix  and  Intel  based  personal  computers  and  workstations.)  All  of  these 
machines  have  equal  access  to  the  Intranet. 

Platform  independence  also  allows  development  of  applications  for  use  enterprise 
wide  without  having  to  develop  versions  to  support  multiple  operating  systems  and 
hardware  architectures.  Through  the  Open  Database  Connectivity  (ODBC)  protocol  and 
a  Web  server,  applications  can  be  developed  to  run  on  the  server  and  accessed  by  all 
users  through  each  individual's  preferred  WWW  browser  on  remote  client  workstations. 


10  Bhargava,  Hemant  K.,  et  al.,  "Decision  support  on  demand:  Emerging  electronic 
markets  for  decision  technologies",  Decision  Support  Systems,  The  International  Journal, 
vol.  19,  no.  3,  pp.  193-214. 
http://dnet.as.nps.navy.mil 
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Training  costs  are  also  kept  lower  with  platform  independence.  Users  only  need  to  learn 
how  to  use  a  WWW  browser  and  the  few  specific  actions  that  a  button  may  perform  on  a 
particular  web  page.  The  printing,  saving  and  sending  of  information  is  all  handled 
through  the  combination  of  the  WWW  browser  on  the  client  machine  and  Webserver 
located  on  the  server. 

Access  can  be  limited  to  the  local  or  a  specific  set  of  IP  addresses  while  still 
maintaining  a  connection  to  the  Internet  through  the  same  LAN.  This  access  restriction  is 
a  function  of  the  Intranet  server  software  and  does  not  require  any  additional  hardware  or 
overhead.  Limiting  access  to  a  specific  range  of  IP  addresses  will  not  effect  Internet 
access  or  Intranet  access  in  any  way  other  than  prohibiting  access  to  unauthorized  users. 

An  additional  measure  of  security  can  be  implemented  to  further  segment  how 
information  access  is  granted.  Since  all  access  is  made  through  preformatted  queries 
contained  in  HTML  pages  that  are  stored  on  the  Intranet  Server,  new  queries  cannot  be 
introduced  to  the  system  without  the  approval  of  the  administrator.  This  characteristic 
also  allows  access  to  the  various  queries  and  pages  to  be  segmented  by  the  directory  file 
system.  This  access  control  is  accomplished  by  assigning  user  names  and  passwords  for 
system  access,  and  further  restricting  access  to  pages  to  individuals  or  groups/types  of 
users. 

Security  is  important  to  insure  that  your  information  is  safeguarded  from  change, 
loss  or  destruction  so  that  the  value  of  the  information  is  not  lost.  When  considering 
security  and  access  the  user  must  define  how  he  or  she  wants  to  segment  or  allow  access 
to  different  parts  of  the  information  database. 


When  increasing  the  availability,  security  must  be  considered  to  prevent  open 
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access  to  information.  The  Intranet  security  can  be  set  to  allow  access  from  a  very 
narrow  range  of  IP  (Internet  protocol  -  the  logical  address  of  a  particular  computer  in  a 
network)  addresses  on  a  local  area  network  (LAN),  to  literally  unlimited  worldwide 
access  via  the  Internet. 

Additionally,  one  can  search  the  Internet  Sites  of  the  many  vendors  of  Internet 
Tools  for  examples  of  their  products.  One  such  site  is  http://www.allaire.com.  This  site 
is  run  by  the  developers  of  the  Cold  Fusion  Database  Tools  used  by  the  Authors  for  their 
prototype. 

Although  many  organizations  have  developed  Intranets  and  DSS  on  those 
Intranets,  there  are  not  many  public  examples.  By  the  very  nature  of  the  Intranet  being 
internal  to  an  organization  and  supporting  internal  functions,  Intranets  are  not  open  to 
public  investigation  or  browsing.  Many  of  the  Intranets  were  developed  to  gain  some 
form  of  competitive  advantage  and  are  therefore  highly  secured. 

One  interesting  link  from  this  site  is  http://www.collegeselect.com/.  This  site  is 
typical  of  the  capabilities  of  database  supported  Internet  DSS.  The  decision  problem  for 
this  site  is  the  selection  of  a  college  or  university  based  on  multiple  attributes.  The 
concept  behind  this  site  is  to  help  a  user  select  a  college  or  university  from  all  the 
colleges  and  universities  in  the  United  States  without  the  user  having  to  search  through 
numerous  publications,  advertisements  and  other  sources.  The  developers  of  this  site 
present  the  user  with  a  means  of  selecting  preferences  for  many  of  the  attributes 
associated  with  a  college  or  university.   The  underlying  heuristic  or  algorithm  compares 


12  Troy  Troxler,  Epoch  Networks,  Byte,  v.  22,  no.  5,  pp.  88b,  April  1997 
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all  of  these  attributes  with  information  stored  in  a  database  to  present  the  user  with  a  list 
of  colleges  and  universities  that  match  their  criteria.  The  final  step  of  making  the 
decision  is  left  to  the  user.  In  some  cases  the  query  will  return  only  one  solution.  In  this 
case  the  decision  is  to  either  accept  or  reject  the  recommendation. 

F.  PURPOSE  OF  RESEARCH 

The  purpose  of  this  thesis  is  to  explore  the  capabilities  and  limitations  of  Intranet 
decision  support  systems  (DSS).  The  research  involves  the  development  of  a  prototype 
for  the  administration  of  the  Department  of  Systems  Management  at  the  Naval 
Postgraduate  School  (NPS).  The  prototype  will  explore  the  applicability  and  suitability 
of  current  technology  in  the  area  of  World  Wide  Web  (WWW)  browser  based  database 
access  to  support  the  development  of  an  Intranet  based  Decision  Support  System.  Key 
considerations  will  include  the  following:  ease  of  learning  and  training  the  user  to  use  the 
browser  interface,  security,  functionality,  and  scalability.  The  prototype  is  based  on 
commercial  off  the  shelf  (COTS)  software  products  combined  with  custom  designed 
HTML  pages  to  automate  specific  department  processes. 

G.  METHOD 

The  intended  users  of  this  Intranet  are  the  Faculty  and  administrative  support 
technicians  in  a  curricular  department. 

The  authors  used  a  modification  of  an  Intranet  Development  Methodology  (IDM) 
developed  by  Information  Age,  Inc.  The  IDM  consists  of  nine  basic  steps;  Web  site 
study,  determination  of  customer  requirements,  systems  analysis  and  design, 
determination  of  system  architecture,  implementation  of  the  plan,  system  testing,  iterative 
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development  of  content  and  interface,  formalization  of  procedures  and  documentation, 
and  finally  training.  As  mentioned  earlier,  the  IDM  is  discussed  in  detail  in  Chapter  II. 

H.  SCOPE  OF  RESEARCH 

The  scope  of  this  thesis  is  to  conduct  an  analysis  of  the  Department  of  Systems 
Management  at  the  Naval  Postgraduate  School  to  determine  the  suitability  of  various 
administrative  functions  for  automation  and  for  the  development  of  an  Intranet  based 
DSS.  The  processes  included  in  the  prototype  were  chosen  as  a  result  of  the  analysis  of 
the  number  of  users  affected  and  the  rate  at  which  information  is  updated.  Those 
processes  that  involve  many  users  and/or  involve  data  that  frequently  changes  were 
selected  as  having  high  impact  on  the  department.  The  expected  outcome  of  the  research 
is  that  these  processes  will  benefit  most  from  automation  and  subsequent  information 
sharing  via  an  Intranet. 

I.    DESCRIPTION  OF  THE  PROTOTYPE 

The  prototype  functions  through  the  combination  of  two  software  packages,  a 
Webserver  and  an  ODBC  server.  High  performance  hardware  is  not  a  requirement  for 
any  of  this  software  to  function.  Higher  performance  hardware  will  yield  overall  higher 
server  performance.  This  prototype  runs,  without  special  action  or  intervention,  on 
standard  desktop  personal  computers.  The  primary  server  platform  is  a  Pentium  166 
MHz  machine,  with  128  MB  RAM  and  a  single  1  OBaseT-ethernet  connection  to  the 
LAN.  This  Intranet  Webserver  is  not  the  same  machine  as  the  network  server.  In  fact, 
the  prototype  will  run  on  a  peer  network.  The  only  network  requirement  is  that  TCP/IP 
be  installed  as  one  of  the  network  protocols. 
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In  addition  to  this  platform,  the  prototype  has  been  tested  on  both  a  486  class  (20 
MB  RAM,  80  MHz)  machine  and  a  133MHZ  Pentium  (32MB  RAM)  machine.  The 
authors  conducted  a  test  to  evaluate  the  perceived  performance  benefit  of  different  server 
platforms.  The  test  involved  running  a  query  to  retrieve  an  E-mail  address  from  the 
database  based  on  a  search  of  Lastnames.  There  was  a  noticeable  difference  noted  in  the 
speed  in  which  queries  were  answered  between  the  486  and  either  of  the  Pentium 
machines.  The  test  took  over  1  minute  when  the  486  CPU  machine  was  the  server.  The 
same  query  took  less  than  2  seconds  on  the  Pentium  based  server.  In  order  to  have 
identical  network  conditions  (traffic,  bandwidth,  and  noise)  the  query  was  run 
simultaneously  from  separate  clients  on  the  same  network. 

Both  the  ODBC  server  and  the  Webserver  handle  security  for  the  Intranet.  The 
Webserver  is  concerned  with  the  authentication  of  the  user  and  access  rights  to  the 
HTML  and  Database  Markup  Language  (DBML)  pages  and  directories.  DBML  pages 
contain  codes  and  commands,  similar  in  form  to  HTML,  that  are  interpreted  by  the 
ODBC  server.  The  ODBC  server  handles  any  rights,  permissions  and  passwords  for 
access  needed  to  the  actual  database.  The  ODBC  server,  through  the  ODBC  protocol, 
handles  concurrent  access  and  record  locking  that  may  be  necessary  to  handle 
simultaneous  access  by  more  than  one  user. 

HTML  and  DBML  pages  were  created  that  link  to  a  database  of  departmental 
information.  The  pages  are  the  interface  to  provide  a  preformatted  consistent  information 
to  information  that  is  used  in  the  department.  Processes  and  information  were  selected 
that  would  be  most  beneficial  through  an  Intranet  system. 
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Processes  were  selected  on  the  basis  of  the  number  of  users  and  how  frequently 
they  access  a  particular  piece  or  collection  of  information,  versus  the  amount  of  time  and 
effort  required  for  maintaining  the  information.  For  example,  information  that  is  not 
often  accessed  and  is  used  by  one  user  was  determined  to  not  benefit  from  Intranet 
publication.  Information  that  is  accessed  by  many  users  frequently  is  a  prime  candidate 
for  publication  via  an  Intranet. 

Information  contained  in  the  database  includes  instructor  specific  information 
(such  as  e-mail  address  and  phone  number),  class  information  (description,  quarter  and 
year,  projected  enrollment),  textbook  requisition  (class,  quantity),  and  student 
observation  forms  (SOF). 

J.  EXPECTED  BENEFITS  OF  RESEARCH 

This  research  will  result  in  a  design  and  development  methodology  for  the 
Department  of  Systems  Management  at  the  Naval  Postgraduate  School.  The  Intranet 
Design  Methodology  explained  in  Chapter  II  can  be  applied  to  any  organization 
considering  development  of  an  Intranet. 

A  second  benefit  of  this  research  will  be  a  prototype  for  selected  administrative 
processes  for  the  Department  of  Systems  Management.  This  prototype  will  be  used  to 
demonstrate  the  ease  of  implementation  and  the  capabilities  that  an  Intranet  can  provide. 

A  third  benefit  is  that  in  addition  to  testing  and  demonstrating  the  ability  to 
rapidly  develop  applications,  the  prototype  will  function  as  a  model  for  other  department 
level  Intranets  at  the  Naval  Postgraduate  School.  A  preliminary  demonstration  of  the 
prototype  to  selected  department  faculty  and  administrators  generated  a  lot  of  interest 
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regarding  the  value  and  benefit  of  such  a  tool  for  the  department  and  the  Naval 
Postgraduate  School. 

K.  THESIS  ORGANIZATION 

Chapter  I  is  an  introduction.  It  includes  the  purpose  of  this  thesis  with  details  on 
broad  benefits  of  basing  DSS'  on  the  WWW,  discussion  of  technologies  that  support 
Intranet  development,  and  an  outline  of  the  remainder  of  thesis.  Chapter  II  details  the 
Intranet  Development  Methodology.  Chapter  III  is  a  description  of  the  department 
process  analysis,  detailing  how  the  system  was  defined,  including  a  description  of  the 
current  system,  customer  requirements,  systems  analysis  and  design,  and  the  system 
architecture.  Chapter  IV  describes  the  Intranet  design.  Chapter  V  lists  implementation 
issues.  Chapter  VI  is  a  summary  with  conclusions  and  recommended  areas  for  future 
research.  There  are  also  four  appendices.  Appendix  A  is  the  process  data  flow  diagrams. 
Appendix  B  is  copies  of  department  forms  and  reports.  Appendix  C  is  a  user's  manual. 
Appendix  D  is  an  administrator's  manual.  Appendix  E  is  a  data  dictionary. 
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II.  INTRANET  DEVELOPMENT  METHODOLOGY 

A.  CHOICE  OF  THE  SYSTEM 

The  Department  of  Systems  Management  was  chosen  as  a  candidate  for  an 
Intranet  system,  because  of  the  limited  functionality  of  the  existing  computer-based 
information  system  for  supporting  business  processes  conducted  on  a  weekly,  quarter, 
and  yearly  basis  for  the  department.  Although  connected  to  the  university  on  a  LAN 
based  system,  the  information  system  is  minimal.  In  general,  the  department  was  familiar 
with  some  of  the  benefits  of  an  Intranet  system  and  therefore  was  receptive  to  the  idea  of 
migrating  their  daily  processes  to  a  more  automated  means.  This  is  an  in-depth  study  of 
the  entire  system  in  detail  to  understand  the  existing  information  flows  and  to  identify 
opportunities  for  improvement  best  suited  for  the  academic  environment. 

1.  Goal  of  the  Intranet  System 

The  goal  in  developing  this  system  is  to  automate  and  streamline  those  highly 
used,  primary  processes  used  by  the  Department  of  Systems  Management  through  a  web 
based  system.  By  applying  state-of-the-art  technologies  in  Intranet  development,  a  tool 
will  be  developed  for  use  by  the  administration,  faculty  and  students,  which  will  reduce 
time  and  save  money,  with  marked  benefits  in  amplifying  individual  efficiency  and 
productivity. 

2.  Development  Process 

To  determine  the  department's  needs,  a  top-down  design  method  was  used.  The 
flexibility  of  the  top-down  design  method  permits  breaking  the  large  picture  into  smaller 
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parts  or  subsystems13.  The  resulting  hierarchical  modular  structure  allows  visualization 
of  the  synergy  between  the  interfaces  of  the  subsystems. 

The  important  advantages  of  the  top-down  approach  are  that  it  avoids  chaos  in 
designing  a  system  all  at  once,  allows  the  designers  to  work  in  parallel  on  different,  but 
necessary  subsystems,  and  the  simplicity  involved  prevents  the  designers  from  getting  so 
mired  in  detail  that  they  loose  site  of  what  the  system  is  really  supposed,  to  attain14. 

The  specific  top-down  technique  chosen  is  a  modification  of  the  Intranet 
Development  Methodology  (IDM) 15  developed  by  Information  Age,  Inc.,  a  website  and 
software  development  company.  The  technique  is  very  similar  to  the  systems 
development  life  cycle  developed  by  Kendall  and  Kendall16.  The  modified  IDM  process 
used  to  assess  the  department  and  is  depicted  in  Figure  1 . 


13  Kenndall,  Kenneth  E.  and  J.E.  Kenndall,  Systems  Analysis  and  Design,  3rd  edition, 
pp.  736  -  737,  Prentice  Hall,  Englewood  Cliffs,  New  Jersey,  1995 
"ibid.  p.  736 - 737. 

15  Bakke,  Bonita,  "Intranet  Development  Strategy", 

http://www.informationage.com/ppr_authorsbsite.htm,  Information  Age,  Inc.,  Nov.  13, 
1996. 

16  Kenndall,  Kenneth  E.  and  J.E.  Kenndall,  Systems  Analysis  and  Design,  3rd  edition,  pp. 
7-12,  Prentice  Hall,  Englewood  Cliffs,  New  Jersey,  1995 
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Figure  1:  Modified  IDM  Process 

A  brief  explanation  of  each  phase  of  the  modified  IDM  process  and  the  results  of 
conducting  these  phases  are  explained  below. 

a.  Web  Site  Study 

This  phase  involved  a  detailed  study  the  existing  system,  to  identify 
bottlenecks  in  information  flow  and  opportunities  for  improvement.  The  results  of  the 
study  were  used  to  determine  the  need,  relevance,  and  potential  impact  of  Intranet 
support  to  various  components  of  the  system.  This  information  was  then  used  to  develop 
a  time  line  and  rough  estimate  of  cost  of  system  hardware  and  software  needs,  as  well  as, 
the  cost  of  development. 

b.  Customer  Requirements 

The  requirements  of  customers  were  obtained  primarily  using  interviews. 
The  fact-finding  mission  of  this  phase  helped  in  identifying  problems,  opportunities,  in 
clarifying  objectives,  and  information  requirements.  The  top-down  methodology  for 
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determining  these  requirements  proved  practical  for  this  study.  Gathering  details  of 
overall  user  needs  and  system  requirements  and  assembling  this  information  to  analyze 
the  current  processes  provided  abundant  material  to  generate  formalized  customer  needs. 
Further  results  obtained  through  use  of  this  research  method  yielded  an  organizational 
structure,  business  functions  performed,  and  outside  entities  affected  by  the  use  of  an 
Intranet  application.  Moreover,  this  helped  in  determining  whether  existing  application 
systems  could  be  used  within  the  Intranet  system. 

Aside  from  interviews,  forms  and  reports  used  by  the  department  were 
collected  to  assist  in  detennining  customer  requirements,  enabling  familiarity  with 
information  the  customer  uses  on  a  daily,  weekly,  and  quarterly  basis.  The  forms  and 
reports  were  used  to  develop  identical  HTML  based  forms  for  migration  onto  the  web. 
This  allowed  the  information  to  be  kept  in  a  format  that  was  familiar  to  the  user. 
Involving  the  user  in  the  research  phase  yielded  numerous  benefits,  including  instant 
feedback,  reduction  in  the  amount  of  training  and  lowered  resistance  to  change  due  to 
unfamiliar  media  and  formats. 

c.  System  Analysis  and  Design 

After  gathering  all  of  the  customer's  requirements  of  the  major  processes 
involved  were  developed.  This  was  then  transformed  into  high  level  through  primary  data 
flow  diagrams  (DFDs)  (Appendix  A).  This  provided  an  understanding  of  the  entity  to 
process  relationships  by  grouping  related  business  functions  and  possible  computer 
processing  requirements.  Data  Flow  Diagrams  allowed  selection  of  a  logical 
implementation  plan  for  an  Intranet  system,  and  further  define  project  time  and  costs. 
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d.  System  Architecture 

This  phase  of  the  process  is  mainly  concerned  with  the  application  of  the 
current  process.  Since  there  was  no  current  automated  application  available,  a  study  of 
the  relative  equipment  configuration,  software  used  in  day  to  day  activities,  and  the 
network  design  that  would  allow  migration  to  the  Intranet  was  conducted.  Since  there 
were  no  current  automated  processes,  and  therefore  no  electronic  database  within  the 
department  to  migrate,  data  migration  was  not  evaluated.  An  assessment  of 
telecommunications  requirements  needed  by  the  Education  Technician  or  Server 
Administrator,  or  whoever  is  placed  in  the  position  to  maintain  the  Intranet  system  is 
described  within  customer  requirements  of  Chapter  III. 

e.  Implementation  Planning 

After  developing  a  sound  design  and  architecture  for  the  system, 
consideration  must  be  given  to  Intranet  start-up  procedures.  This  process  is  continuous 
and  iterative  and  must  be  considered  at  each  step  in  the  modified  IDM  process.  Products 
resulting  from  this  stage  are  definitive  hardware  and  software  requirements,  conversion 
requirements  for  the  user  information,  and  a  plan  for  implementation.  In  this  thesis,  the 
conversion  requirement  is  specific  to  the  Department  of  Systems  Management.  The 
conversion  of  the  existing  database  of  courses  is  not  essential  to  implementation  of  this 
prototype.  The  prototype  program  will  encompass  departmental  courses  only  and  can  be 
easily  input  into  an  existing  database  system,  currently,  as  there  is  no  computerized 
departmental  database. 
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f.  Iterative  Development 

A  prototype  was  built  rapidly  for  the  customer  to  gain  a  quick  appreciation 
of  the  capabilities  and  possibilities  of  an  Intranet  system.  Once  the  infrastructure  issues 
were  answered,  the  Website  development  was  quick.  "Low  cost,  high-speed 
development  cycles  make  long  debates  over  design  a  waste  of  time."17  The  trend  now  is 
to  get  an  application  into  user's  hands  as  quickly  as  possible. 

The  interviews  permitted  assessment  of  the  highest  priority  tasks  (those 
with  the  highest  impact  and  used  by  the  most  number  of  users),  helped  determine 
recommendations  for  the  technical  architecture  (software,  hardware,  and 
telecommunications)  and  provided  migration  paths  to  implementation,  as  well  as, 
determining  policy  and  operating  issues.  Iterative  development  is  simply  working  within 
the  continuous  loop  of  the  modified  IDM  process  as  depicted  in  Figure  1 ,  continually 
reassessing  progress  and  ensuring  that  departmental  priorities  are  still  valid  and  met. 

g.  System  Testing 

Testing  the  system  means  literally  putting  all  the  pieces  of  the  Intranet 
system  together  ensuring  that  the  system  works  and  provides  the  necessary  information 
and  correct  integration  of  manual  and  computer  activities. 

The  testing  strategy  used  to  satisfy  this  requirement  was  to  determine  an 
objective,  define  tasks  and  responsibilities  within  the  team,  define  procedures  for  testing 
by  including  the  user,  document  test  results  through  printouts  of  the  products  produced  by 
the  prototype,  and  implement  necessary  program,  design,  and  documentation  changes. 


17  Vinson,  $am,  "Intranet  Politics  and  Technologies",  Byte,  v.  22,  no.  5,  pp.  88a-88h, 
April  1997 
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The  majority  of  problems  were  found  directly  through  programming  and 
testing  of  the  Cold  Fusion  code.  The  concluding  deliverable  for  this  phase  was  to 
implement  a  demonstration/validation  of  portions  of  the  Intranet  to  a  test  bed  of  students 
and  faculty.  This  not  only  proves  the  Intranet  system  and  the  system's  value,  but  also 
allows  the  user  to  get  a  feel  for  the  system  and  provides  immediate  test  feedback  to 
implement  necessary  changes. 

h.         Procedures  and  Customer  Documentation 

This  phase  of  development  deals  with  defining  and  documenting  the 
manual  and  customer  procedures  that  support  and/or  interface  with  the  automated 
application  system.  The  documentation  is  written  at  a  level  that  the  customer 
understands.  The  documentation  links  the  manual  and  automated  components  of  the 
system. 

The  deliverables  for  this  portion  include  the  following: 

a.  Data  Notebook  including  a  copy  of  the  printed  code  and  associated  web 


page. 


b.  System  Overview 

c.  General  Description 

d.  Intranet  Interfaces 

e.  Key  terms 

f.  System  documentation  overview 

g.  User  procedure  manual 

h.  System  documentation  manual 
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Each  of  these  deliverables  will  be  discussed  in  detail  in  Chapter  III  and  the 
User's  and  Administrator's  manuals. 

i.  Training 

This  phase  is  most  critical  for  the  administrator  who  will  be  charged  with 
maintaining  and  continually  developing  the  system  as  department  needs  change.  This 
phase  is  also  used  to  support  training  of  the  primary  user,  the  Department  of  Systems 
Management's  Ed  Technician  on  the  use  of  the  system.  User  training  sessions  will  not  be 
as  extensive,  since  the  customer  was  kept  involved  for  most  of  the  development  and  rapid 
prototyping. 

Ease  of  training  was  a  design  goal  for  this  prototype.  The  authors 
deliberately  built  pages  that  have  only  a  few  possible  action  buttons  and  much  of  the 
input  is  done  with  drop  down  boxes.  Ease  of  training  is  one  of  the  primary  benefits  of 
Intranet  based  information  publishing.  The  only  application  a  user  need  learn  is  the  use 
of  a  web  browser  and  any  specific  actions  for  enterprise  specific  pages.  The  WWW 
browser  and  Webserver  handle  all  printing,  saving  and  formatting.  It  was  assumed  that  a 
general  level  of  knowledge  of  web  browsers  and  underlying  basic  HTML  authoring 
techniques  and  the  use  of  email  exists  within  the  department,  composed  of  about  50% 
Information  Technology  professionals. 
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in.  SYSTEM  DEFINITION  PHASE 

A.  METHOD 

The  purpose  of  this  phase  is  to  study  the  existing  system,  determine  customer 
requirements,  and  develop  logical  process  data  flow  diagrams  for  the  proposed  system. 
This  phase  encompasses  the  first  three  phases  of  the  modified  IDM  model,  Web  Site 
Study,  Customer  Requirements,  and  Systems  Analysis  and  Design  explained  in  Chapter 
II.  System  Architecture  will  be  discussed  briefly,  and  will  be  discussed  in  detail  later  in 
Chapter  IV. 

1.  Web  Site  Study 

The  interview  with  the  Education  Technician  in  the  Department  of  Systems 
Management  allowed  formulation  of  a  specific  need  and  conceptual  application  of  an 
Intranet  for  the  department.  This  phase  is  broken  into  three  parts:  the  current  system, 
anticipated  needs,  and  rough  cost  of  development. 

2.  Background 

The  Naval  Postgraduate  School  Department  of  Systems  Management  is  the 
largest  department  at  the  school.  In  terms  of  being  the  largest,  the  department  houses  over 
500  students  whose  studies  encompass  20  different  areas.  After  an  initial  discussion  with 
the  Information  Technology  Management  Academic  Associate  and  a  subsequent 
interview  with  a  professor  within  the  school's  Department  of  Operations  Research,  the 
enormity  of  the  project  was  realized  and  the  thesis  was  scaled  to  focus  and  concentrate  in 
one  area,  the  Department  of  Systems  Management.  Realizing  that  each  department  is 
different,  a  more  feasible  solution  was  to  concentrate  efforts  to  build  a  rapid  prototype  for 
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Department  of  Systems  Management,  and  at  the  same  time  ensure  its  scalability  and 
migration  ability  to  any  department  at  NPS. 

3.        The  Current  System  and  Deficiencies 

Through  interviews  and  study  of  the  thesis  conducted  by  Nolan  and  Youngblood18 
at  NPS,  a  determination  was  made  that  the  course  scheduling  process  has  not  changed 
since  1958.  In  this  respect,  the  school  still  conducts  scheduling  manually.  The  reasons 
for  not  changing  the  current  system  are  explained  below. 

There  is  considerable  resistance  to  automation  of  the  scheduling  process  and  even 
resistance  to  students  conducting  research  toward  automating  this  process.  This  resistance 
further  supported  the  decision  to  focus  on  one  department.  The  argument  against 
automating  the  process  all  focus  around  the  fact  that  the  problem  is  a  complex 
combinatorial  problem. 

The  Naval  Postgraduate  School  scheduling  system  is  a  unique  "pull"  system. 
Simply  stated,  this  system  is  dependent  on  the  students  who  attend  the  school  and  the 
courses  they  must  take  to  fulfill  their  degree  in  the  time  allotted  for  them  to  be  at  this  duty 
station.  Curriculum  groups  (of  officer  students)  come  in  together  and  graduate  together, 
so  schedules  are  tailored  to  accommodate  these  groups.  Some  new  arrivals  validate 
courses  and  therefore  must  arrange  different  schedules  than  was  initially  given,  however 
the  majority  of  officers  will  have  the  same  schedule  through  their  stay.  Aside  from 
academics,  the  needs  of  the  Navy,  Marine  Corps,  Army,  and  Air  Force  influence  the 


1  o 

Nolan,  Jeffrey  S.  and  P.D.  Youngblood,  "Naval  Postgraduate  School  Scheduling 
Support  System  (NPS)",  Thesis  for  the  Naval  Postgraduate  School,  Monterey,  California, 
March  1992. 
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scheduling  process.  Research  has  not  shown  how  any  automation  will  save  money, 
however  it  has  validated  these  facts.  The  current  system  requires  two  schedulers.  This 
would  also  be  the  requirement  to  run  the  automated  system.  This  is  primarily  due  in  part 
to  the  amount  of  courses  and  number  of  students  serviced.  It  would  be  overwhelming  to 
have  one  individual  keep  up  with  the  scheduling  system  and  secondly,  the  need  for  a 
backup  is  filled. 

As  a  complex  combinatorial  problem  problem,  it  cannot  be  solved  with  an  80- 
90%  automated  solution  with  the  final  10%  being  human  solved.  The  barrier  here,  is  the 
generative  learning  that  goes  on  as  the  initial  scheduling  is  done.  The  early  guidelines  of 
the  problem  and  solution  are  somehow  learned  by  the  schedulers,  asking  a  human  to  step 
in  and  take  up  where  the  computer  left  off  will  not  lead  to  a  solution,  because  the  human 
has  not  had  the  benefit  of  "training"  his/her  brain  throughout  the  process. 

Aside  from  the  amount  of  man-hours  involved  in  constructing  individual  student 
schedules,  there  is  a  consumption  of  an  enormous  amount  of  paper.  Although  getting  the 
schedules  to  paper  is  an  automated  process,  schedulers  still  rely  on  manual  means  to 
assign  students  to  courses  and  courses  to  classrooms. 

The  Department  of  Systems  Management  employs  one  individual,  the  Education 
Technician,  who  is  the  focal  point  of  the  department's  course  scheduling  and 
administrative  tasks.  Most,  if  not  all,  information  produced  in  the  Department  of  Systems 
Management  is  paper  based.  The  Education  Technician  spends  50%  of  actual  work  time 
walking  the  halls  collecting  information  and  paper  forms  from  professors.  This  collection 
time  is  obviously  not  productive  time.  The  information  is  not  readily  available,  nor  is  the 
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information  in  an  acceptable  format  to  warrant  professors  to  take  time  from  their 
schedules  to  write  in  or  type  the  needed  information  on  paper  based  forms. 

Little,  if  any,  information  within  the  department  is  computer-based,  as  discussed 
in  the  previous  chapter.  Most  computer-based  information  resides  in  databases 
maintained  by  the  Registrar  at  NPS.  This  legacy  system  however,  is  becoming  archaic 
and  will  soon  have  to  be  scaled  up.  The  most  efficient  way  to  do  this  is  through  Intranets, 
as  Intranets  take  advantage  of  web  based  technologies  and  can  be  extensively  tied  into 
existing  database  systems.  The  Department  of  Systems  Management  is  an  excellent 
candidate  for  an  Intranet.  The  department  is  in  need  of  a  technology  boost  and  migration 
to  a  web  based  system,  justified  by  the  fact  that  the  only  online  information  used  by  the 
Education  Technician  is  a  database  containing  the  courses  being  offered  during  a 
particular  quarter.  There  is  no  database  used  to  track  significant  data  such  as  faculty, 
textbooks,  courses  (aside  from  course  registration  at  the  Registrar),  course  journals, 
student  observation  forms,  faculty  preferences,  thesis  assessments  or  general  information. 
All  documentation  of  this  type  is  manually  generated  and  paper  based.  The  amount  of 
paper  being  produced  each  quarter  is  phenomenal  and  unwarranted. 

All  personnel  in  the  department  that  are  involved  in  information  generation  and 
processing  have  either  access  to  or  physically  own  a  computer  with  word  processing 
software  and  connection  to  the  department  LAN. 

The  Education  Technician  has  the  following  hardware  and  software  to  conduct 
routine  activities: 

Gateway  2000,  486  DX2  66MHz  processor 

Windows  3.11  Operating  System 
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Primary  software  is  Paradox  for  instructor  and  schedule  database  and 
WordPerfect  (version  5.1  for  DOS)  for  any  memos  or  day-to-day  activities. 

Current  network  connection  is  through  Banyan  Vines,  which  is  used  for  email 
only  and  serves  no  other  function  at  this  time.  There  is  no  direct  link  to  the  Department  of 
Systems  Management. 

The  computer  has  no  TCP/IP  connectivity. 

All  reports  are  prepared  with  WordPerfect. 

Primary  users  of  the  information  must  make  requests  for  specifically  formatted 
reports  directly  to  the  Education  Technician.  (Note.  Primary  users  will  be  discussed  later 
in  this  chapter  under  Customer  Requirements.)  These  reports  include:  Course  Offerings, 
Faculty  Teaching  Assignments,  Faculty  Preferences,  Textbook  Requirements,  End  of 
Course  Journals,  and  Thesis  Advising  and  Thesis  Quality  Assessments.  These  forms  and 
reports  are  the  most  widely  used  by  faculty.  The  forms  listed  above  and  others  used  by 
the  department  can  be  found  in  Appendix  B.  These  forms  and  reports  may  well  be  served 
as  public  domain  for  the  faculty  members,  as  the  database  is  not  shared  with  them. 

Linking  the  database  to  forms  is  conducted  in  a  rather  archaic  fashion.  Manual 
inputs  of  information  are  made  from  the  database  to  the  word  processor  (i.e.  there  is  no 
link  from  the  data  to  the  report).  To  prepare  any  report,  the  education  technician  first 
searches  the  database  (does  not  create  or  run  queries)  and  notes  the  information  needed, 
then  retypes  the  information  into  a  word  processor  employing  the  same  computer  used  to 
retrieve  the  information. 
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4.  Anticipated  Needs 

The  department  is  in  need  of  revamping  the  current  database  system  and  structure. 
This  includes  a  more  current  operating  system,  word  processor,  database  system,  a  web 
server,  dynamic  database  interface  utility  and  component  upgrades  to  the  hardware 
system.  The  specifics  needs  and  recommendations  for  both  hardware  and  software  will 
be  discussed  later  in  Chapter  V,  Implementation  Issues.  Upgrading  hardware  is  a 
relatively  inexpensive  investment,  considering  that  small  upgrades  can  yield  increases  in 
performance  and  efficiency  ten  fold,  i.e.  upgrading  from  a  486  to  a  low  end  (133Mhz) 
Pentium  Processor.  A  need  that  draws  some  attention  is  a  trained  systems  administrator 
who  will  maintain  and  update  an  Intranet  System  once  installed.  Training  is  also  an  issue 
that  will  be  discussed  in  Chapter  V  and  will  include  the  Systems  Administrator, 
Education  Technician,  faculty  and  students. 

5.  Estimated  Cost  of  Development 

Current  cost  of  development  for  the  Intranet  System  to  facilitate  information  flow 
for  existing  processes  is  minimal.  Hardware  and  software  costs  will  run  roughly  $3,000. 
The  rough  estimate  is  based  on  obtaining  a  more  current  Pentium  hardware  system  and 
software  products  such  as  Cold  Fusion,  Microsoft  Office,  Web  Site  (Server  software), 
and  Homesite  (HTML  editor).  These  are  very  rough  estimates  and  consideration  must  be 
taken  in  the  fact  that  hardware  prices  literally  drop  on  a  daily  basis.  By  the  time  this 
thesis  is  produced,  the  rough  cost  could  be  as  low  as  $2,500. 

The  uniqueness  of  this  thesis  allows  for  a  minimal  cost  of  development.  There 
are  no  labor  costs,  since  both  authors  are  students  and  are  paid  by  the  government.  The 
only  costs  incurred  by  the  department  were  for  software,  as  the  computer  system  was 
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borrowed  through  another  professor  in  the  department,  therefore  a  sunk  cost.  Software 
costs  include  Cold  Fusion  at  $199,  Website  Pro  Server  at  $499,  and  Homesite  at  $40. 

6.       Customer  Requirements 

"The  best  way  to  decide  what  to  put  on  an  Intranet  is  to  walk  through  key 
departments  and  find  out  what  bits  of  paper  are  hanging  on  the  wall.  The  reason  they  are 
there  is  for  the  operational  needs  of  the  individuals."19  Aside  from  interviews  conducted 
with  the  department's  Academic  Associate  and  Education  Technician  and  an  initial 
interview  with  a  professor  in  the  Department  of  Operational  Research,  this  was  literally 
the  approach  taken.  As  students  at  the  school,  the  authors  have  first  hand  knowledge  of 
information  requirements  and  qualified  us  as  customers  of  information  to  determine  these 
requirements.  Walking  the  halls  of  the  department  and  reviewing  information  posted  on 
bulletin  boards  validated  information  needs. 

The  Academic  Associate  provided  insight  to  a  development  strategy  and  in  areas 
to  focus.  The  Academic  Associate  assisted  in  better  defining  roles  of  individuals  in  the 
Department  of  Systems  Management  and  relationships  to  entities  on  campus.  A  concern 
raised  during  this  interview  was  his  specific  lack  of  faith  in  the  FOCUS  Database  system 
now  used  by  the  school.  The  format  of  information  presented  by  FOCUS  cannot  be 
modified  to  fit  this  need;  therefore,  the  user  perceives  little  value  returned  for  his/her  use 
and  the  system  then  becomes  user-unfriendly.  FOCUS  is  provided  to  all  professors  in  the 
department,  but  because  of  the  interface,  avoided  as  much  as  possible  (FOCUS  is  the 


19Schwartz,  Karen  D.,  "Weaving  an  Internal  Web",  DoDIT,  an  Army,  Navy,  Air 
Force  Times  Marketing  Supplement,  May  19,  1997. 
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primary  tool  for  the  Education  Technician  within  the  curricular  office  to  input  and 
retrieve  information  to  and  from  the  registrars'  office). 

An  interview  with  the  Operations  Research  professor  was  helpful,  in  restricting 
the  scope  of  this  thesis  to  one  department  and  excluding  course  scheduling. 

Course  Scheduling  was  still  a  concern.  Although  the  product  of  this  thesis  is  to 
develop  an  Intranet  for  information  sharing  for  the  department,  there  still  exists  a  need  to 
develop  some  type  of  course  scheduling  database  that  is  easily  manipulated  by  students 
and  faculty.  For  this,  a  common,  but  robust  database  system  would  need  to  be  developed 
to  implement  course  scheduling  or  at  least  a  storage  media  for  courses  being  offered  for  a 
particular  quarter  or  variety  of  quarters.  An  important  fact  when  designing  the  database 
is  that  33%  of  students  change  their  schedule  within  the  first  two  weeks  of  class  each 
quarter.20  Moreover,  students  must  have  this  type  of  availability  to  easily  access  a  site 
which  presents  them  with  the  courses  required  to  complete  their  degree,  offers  the  ability 
to  manipulate  the  schedule  based  upon  NPS  requirements  and  their  needs,  and  offers 
Education  Technicians  the  ability  to  simply  manage  an  HTML  page  and  make  necessary 
updates  based  on  instructors,  courses,  and  classrooms. 

The  most  significant  information  was  obtained  from  the  Education  Technician, 
who  will  be  a  direct  user  of  the  Intranet  system,  if  not  one  of  the  maintainers.  The 
Education  Technician  serves  as  the  liaison  between  the  NPS  Schedulers  and  the 
department  and  also  liaison  between  the  curricular  office  and  the  department.  The 
current   information   requirements   essential   to   the   Education  Technician   are   class 


Interview  with  Professor  Gordon  Bradley,   Professor  Department  of  Operations 
Research,  Naval  Postgraduate  School,  Monterey,  CA,  25  October  1996. 
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schedules,  courses,  student  data,  faculty  data,  and  course  data  including  instructors, 
students,  classrooms,  journals,  and  textbooks.  The  current  hardware  and  software  system 
in  place  for  the  Education  Technician,  as  discussed  previously  in  this  chapter,  is  a 
limitation. 

The  current  manual  information  system  was  found  to  be  inadequate  for  the 
department.  Information  support  to  faculty  members  is  lacking  through  no  fault  of  the 
departments.  The  responsibilities  of  the  Education  Technician  include:  Student 
validation,  dissemination  and  collection  of  the  Student  Observation  Forms  (SOFs), 
faculty  registration  and  assignments,  faculty  preferences/requirements  worksheets,  thesis 
advising  and  thesis  quality  assessment  reports,  and  systems  management  end  of  course 
journals,  and  textbook  ordering.  Copies  of  each  of  these  forms  and  reports  are  contained 
in  Appendix  B. 

One  of  the  major  outcomes  of  the  analysis  of  customer  requirements  was  the 
identification  of  the  individuals  (entities)  involved  in  the  processes  being  developed. 
The  key  entities  include  the  following:  department  education  technician,  curricular  office 
education  technician,  faculty,  students,  associate  chair  for  instruction,  schedulers, 
database  administrator  for  the  registrars  office,  department  chair,  and  the  department 
academic  associates.  The  current  organization  structure  for  the  department  is  found  at 
Figure  2,  which  depicts  only  the  relevant  entities. 
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Figure  2:  Relevant  Entities 

7.        Systems  Analysis  and  Design 

Through  the  interviews,  entities  for  systems  analysis  and  design  were  discovered. 
"A  large  part  of  systems  analysis  and  design  involves  working  with  current  and  eventual 
users  of  the  information."  Copies  of  current  forms  and  reports  were  collected  to  use  as 
formats  for  the  information  system.  A  design  goal  was  to  present  an  interface  that  closely 
resembled  current  paper  based  means.    This  approach  presents  a  consistent  interface  to 


21Kermdall,  Kenneth  E.  and  J.E.  Kenndall,  Systems  Analysis  and  Design,  3rd  edition,  p. 
5,  Prentice  Hall,  Englewood  Cliffs,  New  Jersey,  1995 
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the  users.  The  processes  for  systems  analysis  and  design  are  Course  Support,  Student 
Observation  Forms,  Thesis  Topic,  Student,  Advisor  Recording,  Course  Validation 
tracking  and  reporting,  End  of  Course  Journals,  and  Thesis  Assessment  Reports.  The 
entity  to  process  relationship  Level  1  Process  Diagram  is  shown  in  Appendix  C  and  is 
explained  in  detail  below. 

a.        Course  Support 

The  Course  Support  process  is  the  largest  of  the  processes.  This  process 
is  further  broken  down  into  five  subprocesses.  The  subprocesses  are  inputs  to  NPS 
schedulers,  schedule  validation,  assignment  of  resources  which  includes  assignment  of 
faculty  to  instruct  courses,  faculty  preferences,  assignment  of  students,  textbook  ordering, 
and  administrative  tasks  such  as  updating  and  deleting  faculty  and  courses.  Subprocesses, 
inputs  to  NPS  schedulers,  schedule  validation,  assignment  of  resources,  faculty 
preferences,  assignment  of  students,  and  textbook  ordering,  follow  a  logical  sequential 
flow  and  cannot  be  completed  in  parallel.  The  database  administration  task  is  the  only 
subprocess  that  can  be  accomplished  at  any  time,  in  parallel  to  the  complementary 
subprocesses.  Level  two  and  three  data  flow  diagrams  for  Course  Support  can  be  found  in 
Appendix  C. 

Although  large,  the  course  support  process  is  a  simple  process.  The 
department's  Education  Technician  consolidates  course  requirements  from  the 
department  and  curricular  offices  and  validates  these  entries  to  ensure  that  there  are 
enough  (at  least  nine)  students  requesting  a  specific  course.  If  there  are  not  enough 
students  requesting  a  particular  course,  a  memo  is  sent  to  the  Curricular  Office  stating 
that  the  particular  course  will  not  be  offered. 
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The  validated  course  requirements  are  submitted  to  the  campus  wide 
database  administrator  who  is  responsible  for  input  of  all  scheduling  information  into  the 
scheduler's  database.  The  database  administrator  provides  tailored  department  specific 
quarterly  course  listings  to  each  NPS  Department. 

The  Department  of  Systems  Management  Education  Technician  validates 
the  returned  schedule  (first  iteration)  by  noting  courses  needed  (from  student  and 
curricular  office  input)  and  the  number  of  students  in  each  class.  Two  reports  are 
produced  from  the  first  iteration.  The  first  report  is  a  Course  Listing  Worksheet  for  the 
particular  quarter  in  question.  This  worksheet  is  used  to  produce  the  second  report, 
"Course  Offerings,  x  Quarter  19xx"  .The  worksheet  shows  the  courses  offered,  number  of 
students  enrolled,  number  of  sections,  number  of  sections  required,  academic  year 
scheduled  sections,  and  any  comments  needed  for  clarification.  As  stated  previously,  the 
courses  are  validated  to  ensure  that  each  has  enough  students  requiring  the  course  and  if 
not  the  course  is  canceled  for  that  particular  quarter. 

The  second  iteration,  which  implements  the  changes,  noted  from  the  first 
iteration  and  is  validated  for  gross  errors  or  omissions.  The  Education  Technician  uses 
the  second  iteration  to  assign  faculty  members  to  each  course.  Upon  notification  the 
faculty  member  provides  input  of  any  special  requirements  for  that  subject/course,  using 
the  Faculty  Preference  worksheet  at  Appendix  B.  These  requirements  may  be  labs, 
special  software,  class  size,  or  other  scheduling  constraints. 

Text  ordering  is  the  final  step  of  the  course  support  process.  After 
submitting  preferences  to  course  instruction  to  the  Education  Technician,  the  faculty 
member  provides  information  on  the  textbooks  required  for  the  course  of  instruction.  The 
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Education  Technician  receives  blank  forms  from  the  Naval  Exchange  (NEX).  The  form 
is  called  the  textbook  worksheet  and  is  a  multi-sheet  form.  Once  complete  the  back  copy 
is  retained  and  two  copies  are  forwarded  the  NEX.  A  general  business  rule  is  that  one 
textbook  ordering  form  is  used  for  each  faculty  member  for  each  course  he/she  is 
teaching.  The  faculty  member  teaching  the  course  and  the  Associate  Chair  for  Instruction 
requesting  the  textbook(s)  must  sign  each  form.  This  process  seems  a  bit  unnecessary  as 
there  are  two  individuals  that  must  verify  with  signatures  that  the  book  requested  is 
needed  and  moreover,  having  one  textbook  ordering  form  per  instructor  and  course  yields 
much  redundant  paperwork.  The  solution  is  to  have  one  consolidated  spreadsheet  or 
requisition  per  department  or  if  the  department  is  large  enough,  a  consolidated 
spreadsheet  per  curriculum  within  the  department  each  with  a  single  signature  by  the 
Associate  Chair  for  Instruction.  Currently  the  process  requires  the  Education  Technician 
to  deliver  these  forms  to  the  NEX  for  processing.  Automating  this  processing  by  linking 
the  NEX  to  the  Intranet  would  alleviate  paper  altogether.  This  change  involves  the 
change  of  a  current  business  rule  and  will  be  addressed  again  later  in  Chapter  V, 
Implementation  issues. 

The  final  process  of  the  course  support  is  grouped  here  simply  because  the 
process  involves  faculty  and  courses  and  provides  a  maintenance  aspect  for  this  process. 
The  ability  of  the  Education  Technician  to  control  the  input,  updating,  and  deletion  of 
courses  and  faculty  members  as  courses  are  added  and  faculty  arrive  and  depart  is  an 
important  aspect  of  any  database  system  and  the  process  can  be  easily  migrated  to  an 
Intranet  system.  Currently,  there  is  no  automated  system  in  place  to  accomplish  this  task. 
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b.  Student  Observation  Forms  (SOFs) 

Each  quarter  students  complete  these  evaluations  on  the  instructors  with 
whom  they  are  taking  classes.  Attributes  of  the  SOF  are;  course  number,  segment 
(section),  instructor  name,  report  number  (to  fields  -  sub  sof  #  and  sof  #),  curriculum 
specialty  #  (for  the  student),  hrs  student  taking  this  quarter,  #  of  quarters  completed, 
whether  the  course  is  required  or  elective,  16-20  questions  (17  -20  are  optional/extra 
questions)  and  a  space  for  open  format  questions. 

The  current  SOF  Process  involves  sealed  envelopes  starting  at  the 
schedulers  routing  through  the  Education  Technician  to  the  student,  forms  are  filled  out 
by  the  student,  returned  to  the  Education  Technician  in  a  sealed  envelope,  then  returned 
to  the  schedulers  for  processing.  The  Education  Technician  only  performs  a  routing  and 
accountability  function  within  the  department.  During  processing  by  the  schedulers,  mean 
scores  and  a  write  up  are  completed  for  each  faculty  member.  A  Department  Chair  report 
is  prepared  that  shows  faculty  members  mean  scores.  Written  comments  are  consolidated 
and  sent  to  each  faculty  member.  Because  of  the  sensitive  nature  of  both  reports,  the 
reports  are  not  included  as  part  of  an  appendix  in  this  thesis.  The  Education  Technician's 
function  is  only  to  route  these  reports  to  the  appropriate  instructor  for  their  review. 

c.  Thesis  Topic/Student/Advisor  Recording 

The  Education  Technician  records  the  title,  student  name  and  advisors  for 
each  thesis.  This  information  is  obtained  from  thesis  proposals.  For  advisors,  the 
Education  Technician  also  records  the  role  (Advisor,  Co-Advisor,  or  Associate  Advisor) 
of  the  faculty  members  involved. 
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d.        Course  Validation  tracking  and  reporting 

The  Education  Technician  is  also  involved  in  determining  eligibility  of 
students  for  certain  course  validations  prior  to  them  arriving  at  NPS.  The  Education 
Technician  records  the  courses  validated  by  each  student  in  the  department.  The 
Education  Technician  also  must  track  and  report  validation  statistics  for  any  classes 
validated  while  a  student  is  enrolled.  The  ability  for  students  that  have  had  prior 
experience  or  course  work  in  a  particular  subject,  to  "test  out"  and  open  up  their 
schedules  for  other  opportunities  or  course  work  at  NPS  or  even  early  graduation.  The 
Education  Technician  conducts  this  process,  as  time  permits,  between  working  with 
Course  Journals  and  the  Thesis  Assessments.  After  the  Education  Technician  sends  the 
NPS  Schedulers  the  second  iteration  of  the  schedule,  newly  arriving  student  transcripts 
are  pulled  and  reviewed  to  determine  if  a  student  is  in  a  position  to  validate  any  courses. 
There  are  two  lists  of  available  classes  for  validation,  one  for  370  (Information 
Technology  Management  (ITM))  and  another  for  all  800  series  curricula.  The  Education 
Technician  determines  acceptability  by  reviewing  courses  shown  on  the  student's 
transcripts  with  a  list  of  classes  open  for  validation.  If  a  student  is  determined  to  meet  the 
criteria  to  attempt  validation,  a  cover  sheet,  validation  form  (Appendix  B),  and  the 
student's  transcripts  are  sent  to  the  instructor  with  responsibility  for  a  particular  course. 
When  the  new  student  arrives  at  NPS  he/she  will  be  informed  by  the  Academic  Associate 
what  classes  can  be  validated.  Validation  can  take  place  via  three  methods  (each  of  these 
methods  are  course  dependent):  Validation  through  transcripts,  Validation  through 
interview,  and  Validation  through  examination. 
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If  there  is  an  examination  involved,  the  Education  Technician  is 
responsible  for  administering  and  grading  the  exams  to  determine  if  the  student  gets 
validation  credit.  Completed  validation  forms  go  to  the  curricular  office.  The  curricular 
office  provides  input  and  signatures,  then  sends  the  validation  to  the  Department  of 
Systems  Management  for  final  approval. 

Prior  to  the  Academic  Year  1997,  the  Education  Technician  produced  a 
report  (Appendix  B)  detailing  statistics  of  classes  validated  by  only  incoming  students  by 
quarter.  This  year  the  report  will  detail  all  classes  validated  (existing  students  and  new 
students).  This  report  goes  to  the  department's  Associate  Chair  for  Instruction. 

The  report  can  have  many  formats:  by  student,  by  class,  by  student  type 
(new  or  "veteran"),  by  curriculum,  by  quarter,  by  year.  Currently,  completed  validation 
forms  are  not  routed  to  the  Education  Technician  from  the  curricular  office.  The 
education  technician  must  physically  go  to  the  curricular  office  education  technician  for 
this  information. 

e.        End  of  Course  Journals 

At  the  end  of  each  quarter  a  course  journal  is  prepared  by  a  professor(s) 
teaching  a  particular  course.  The  end  of  course  journals  provide  the  department  with  four 
pieces  of  key  information.  First,  these  journals  provide  new  instructors  with  the 
information  and  ideas  about  what  have  been  form,  format,  and  experience  in  teaching  a 
particular  course.  Second,  they  provide  the  faculty  colleagues  with  readily  available 
information  about  the  level  and  nature  of  preparation  of  students  who  will  be  entering 
their  courses.  Third,  the  journals  also  provide  the  department  with  a  comprehensive 
"corporate  memory"  on  the  content  and  recent  experience  of  classroom  instructional 
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program.  Lastly,  they  provide  the  chairman  with  additional  data  for  annual  performance 
appraisals  for  individual  faculty  members. 

The  course  journals  are  also  a  good  reference  in  providing  detailed 
specifics  in  regards  to  textbooks  used  and  class  grade  distribution.      These  journal 
documents  should  not  be  accessible  by  students. 
f.        Thesis  Assessment  Reports 

Thesis  Quality  Assessment  Surveys  are  completed  at  the  end  of  each 
quarter.  This  report  provides  the  Systems  Management  faculty  a  complete  picture  of  what 
they  think  about  the  value  of  the  theses  they  were  involved.  The  report  indicates  how  the 
faculty  is  doing  and  suggests  where  and  how  the  faculty  member  can  improve  in  making 
the  thesis  a  valuable  educational  experience  that  contributes  to  both  the  student's  future 
career  success  and  also  help  the  Department  of  Defense  (DoD)  more  effectively  address 
its  current  and  anticipated  challenges. 

8.        Process  Analysis  of  Key  Processes 

Level  two  and  three  data  flow  diagrams  (Appendix  C)  further  break  down  the 
higher  level  processes  to  their  primary  elements  yielding  products  which  show  individual 
tasks  conducted  by  each  process  and  their  interaction.  This  further  allows  a 
microanalysis  of  each  process  to  determine  exact  information  needs.  The  following 
paragraph  details  each  process  mentioned  previously,  providing  a  logical  flow  of 
information  to  the  process'  primary  structure.  For  a  process  template  contains  the 
following  information  was  used  for  analysis: 

Entities  Affected.  Properly  identifies  the  individual  or  organization,  which 
interacts  with  the  process  or  acts  on  the  process. 
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Number  of  Users.  Users  in  this  environment  are  restricted  to  Academic 
Advisors,  faculty,  students,  and  the  Education  Technician. 

Primary  Owners.  Primary  Owners  are  those  who  own  the  data,  input  data,  and 
control  output  of  the  data  for  documents  such  as  memorandums  and  reports  submitted  by 
the  department. 

Frequency  of  Use.  This  is  limited  to  the  following  use  criteria:  Daily,  Weekly, 
Quarterly,  and  Annual. 

Frequency  of  Update.  This  is  limited  to  the  following  use  criteria:  Daily, 
Weekly,  Quarterly,  and  Annual. 

Mode  of  Use  by  Entities.  Each  of  the  processes  will  allow  one  of  the  following 
to  take  place:  single  update,  single  query,  multiple  updates,  multiple  queries  or  any 
combination.  Single  update  applies  to  one  entity  or  individual  acted  upon.  This  mode  of 
use  allows  or  requires  the  user  to  make  an  update  on  a  single  entity.  Single  query  allows 
the  user  to  access  information  on  a  single  entity  or  individuals.  Multiple  updates  allow  or 
require  the  user  to  make  multiple  updates  to  several  entities  or  individuals.  Multiple 
queries  allow  the  user  to  access  information  on  multiple  entities  or  individuals. 

Type  of  Information. 

Generic  vs.  Customized:  This  information  applies  to  data,  which  is  either  used 
routinely  or  created  for  a  given  situation  or  need.  A  determination  will  be  made 
specifying  who  the  information  is  pertinent  too  and  when  the  information  would  be 
needed  (daily,  weekly,  quarterly,  and  annual). 
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Privacy  vs.  Non-Privacy:  This  information  applies  to  data,  which  is  either 
sensitive  or  non-sensitive  in  nature.  When  analyzing  each  process  a  determination  will 
be  made  as  to  the  privileges  and  permissions  granted  to  an  entity. 

Classified  vs.  Unclassified:  This  information  applies  to  data  which  is  either 
classified  or  unclassified  as  determined  by  the  Department  of  Defense  (DoD)  and  further 
specified  a  higher  classification  as  determined  by  NPS. 

Source  of  Information:  This  information  applies  to  the  origin  of  data  used  by 
entities. 

Current  Status:  This  element  of  analysis  describes  how  the  current  process  is 
conducted.  It  will  answer  questions  such  as:  Is  the  process  being  conducted  manually  or 
is  it  semi-automated?  Where  is  the  information  stored?  Who  maintains  the  current 
information? 

Miscellaneous  Information:  If  needed,  this  element  of  analysis  will  be  added  to 
cover  any  pertinent  information  not  included  in  the  previous  elements. 

The  template  described  above  will  now  be  used  to  examine  each  of  the  processes 
selected  for  analysis. 

Process  1:  Course  Support 

Entities  Affected:  Education  Technician  (Department  and  Curriculum  Office), 
NPS  Database  Administrator,  Faculty,  and  Students. 

Number  of  Users:  All  Students  and  Academic  Advisors. 

Primary  Owners:  Education  Technician  (Department) 

Frequency  of  Use:  Daily  to  Quarterly 

Frequency  of  Update:  Quarterly 
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Mode  of  Use  by  Entities:  Multiple  Update,  Multiple  Queries 

Type  of  Information: 

Generic  vs.  Customized:  This  information  would  be  customized  for  each  quarter. 
There  will  be  the  ability  to  obtain  generic  course  information  and  course  offerings  each 
quarter.  The  customized  information  would  pertain  to  individual  students  and  faculty 
instructing  classes. 

Privacy  vs.  Non-Privacy:  The  Database  Administrator  and  Education  Technician 
for  the  Department  will  have  Administrator  privileges.  Faculty  and  students  would  have 
limited  use  such  as  update  capability,  however,  a  student  cannot  change  or  view  another 
student's  schedule,  a  faculty  member  cannot  change  a  student's  schedule.  A  business 
rule  would  have  to  allow  students  to  request  change  in  courses  through  both  Ed. 
Technicians  who  would  get  approval  and  input  changes. 

Classified  vs.  Unclassified:  Unclassified  within  the  bounds  of  NPS.  Classified 
outside  the  firewall. 

Source  of  Information:  Course  Catalog  and  Paradox  Database. 

Current  Status:  Scheduling  is  done  manually.  Courses  are  kept  on  a  database. 
The  scheduling  process  is  a  manual  process  with  electronic  filing.  Within  the 
Department  of  Systems  Management  courses  are  kept  on  a  Paradox  Database  System. 

Process  2:  Student  Observation  Forms. 

Entities  Affected:  Department  Chair,  Database  Administrator,  Education 
Technician  (Department),  Faculty,  and  Students. 

Number  of  Users:  Students  and  Faculty. 

Primary  Owners:  Database  Administrator  and  Education  Technician(Department) 
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Frequency  of  Use:  Quarterly 

Frequency  of  Update:  Quarterly 

Mode  of  Use  by  Entities:  Single  Update,  Multiple  Query 

Type  of  Information: 

Generic  vs.  Customized:  Student  Observation  Forms  are  customized  forms  of 
information  relating  the  student  to  the  instructor  and  the  course  taught. 

Privacy  vs.  Non-Privacy:  Must  maintain  privacy.  No  entity  needs  to  know  who 
turned  in  which  SOF  and  its  contents.  The  Education  Technician  (Department)  is  the 
collector  of  SOFs  for  the  department  (given  to  her  in  a  sealed  envelope).  Department 
Chair  is  given  a  Department  synopsis.  Faculty  are  given  the  assessment  and  SOFs  at  the 
beginning  of  the  next  quarter.  Care  is  taken  to  ensure  there  is  no  perception  that  SOF 
input  effect  grades. 

Classified  vs.  Unclassified:  SOFs  are  classified  information  and  must  be  treated  as 
such. 

Source  of  Information:  Database  Administrator  provides  the  necessary  forms. 
Students  provide  the  input. 

Current  Status:  Process  3  is  partially  automated.  Students  provide  assessments  in 
a  Mark-sense  form  and  also  provide  written  comments.  Forms  are  placed  in  a  machine  to 
compile  and  assess  results  (automated  portion  of  the  process).  A  summary  is  provide  by 
the  Registrar  and  provided  to  each  Department  Chair. 

Process  3:  Accounting  and  reporting 
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This  process  combines  two  Level  1  processes,  Thesis  Topic/Student/Advisor 
Recording  and  Course  Validation  as  both  are  closely  related  administrative  tasks 
performed  by  the  Education  Technician,  faculty  and  students. 

Entities  Affected:  Department  Chair,  Associate  Chair,  Education  Technician 
(Department),  Faculty,  and  Students. 

Number  of  Users:  Currently  there  are  78  faculty. 

Primary  Owners:  Education  Technician  (Department) 

Frequency  of  Use:  Daily,  Weekly,  and  Quarterly 

Frequency  of  Update:  Bi- Weekly 

Mode  of  Use  by  Entities:  Multiple  Updates,  Multiple  Queries 

Type  of  Information: 

Generic  vs.  Customized:  Thesis  Topic/Student/Advisor  Recording  will  provide 
customized  information.  Course  Validation  will  provide  generic  information. 

Privacy  vs.  Non-Privacy:  The  Education  Technician  (Department)  will  have 
Administrator  privileges.  Privacy  for  Thesis  Topic/Student/Advisor  Recordings.  Course 
Validation  is  a  simple  matter  of  ensuring  that  a  course  will  be  taught  in  a  given  quarter, 
therefore  requires  non-privacy. 

Classified  vs.  Unclassified:  Topic/Student/Advisor  Recordings  is  classified 
material  from  the  standpoint  of  Professor/Student  relationship.  There  may  need  to  be  the 
ability  to  view  validation  statistics  on  a  generic  basis  with  no  security  limitation.  There  is 
no  need  to  limit  access  to  the  overall  statistics. 

Source  of  Information:  Course  Catalog,  Paradox  Database,  and  previous  quarter 
thesis  recordings. 
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Current  Status:  Process  2  is  done  manually  with  all  documentation  being  recorded 
and  stored  on  a  PC. 

Miscellaneous  Information: 

Process  4:  End  of  Course  Journals 

Entities  Affected:  Department  Chair,  Associate  Chair,  Academic  Associate, 
Education  Technician(Department),  and  Faculty. 

Number  of  Users:  Approximately  150  faculty. 

Primary  Owners:  Education  Technician  (Department) 

Frequency  of  Use:  Quarterly 

Frequency  of  Update:  Quarterly 

Mode  of  Use  by  Entities:  Single  Update,  Multiple  Queries 

Type  of  Information: 

Generic  vs.  Customized:  Course  Journals  provide  a  customized  tool  to  explain 
course  statistics  and  format. 

Privacy  vs.  Non-Privacy:  Information  provided  by  the  faculty  should  be  shared 
with  other  faculty,  but  not  the  student  population. 

Classified  vs.  Unclassified:  Not  applicable. 

Source  of  Information:  Instructor  providing  instruction  for  the  course.  Textbooks 
are  a  source  of  information.  Another  possible  source  of  information  is  through  student 
SOFs. 

Current  Status:  Process  4  is  done  manually  with  all  documentation  being  recorded 
and  stored  on  a  personal  computer. 
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Process  5:  Thesis  Assessment  Reports. 

Entities  Affected:  Department  Chair,  Education  Technician  (Department), 
Faculty,  and  Students. 

Number  of  Users:  Approximately  250. 

Primary  Owners:  Education  Technician  (Department) 

Frequency  of  Use:  Quarterly 

Frequency  of  Update:  Quarterly 

Mode  of  Use  by  Entities:  Multiple  Updates,  Single  Query 

Type  of  Information: 

Generic  vs.  Customized:  Customized  information 

Privacy  vs.  Non-Privacy:  The  Education  Technician  (Department)  will  have 
Administrator  privileges.  Faculty  members  should  not  be  able  to  assess  other  faculty 
reports  or  know  the  points  awarded  to  another  faculty  member.  Information  is  irrelevant 
to  the  student  population. 

Classified  vs.  Unclassified:  Should  be  kept  as  classified  information  within  the 
department  and  released  only  at  the  discretion  of  the  Department  Chair. 

Source  of  Information:  Faculty  and  Student  individual  assessment. 

Current  Status:  Process  5  is  conducted  manually.  Students  and  advisors  fill  in  the 
necessary  information  then  turn  into  the  Education  Technician  (Department). 

9.        Selection  of  the  Prototype  Processes 

Through  the  use  of  the  above  technique  in  analyzing  the  processes  relevant  to  the 
Department  of  Systems  Management,  a  list  of  processes  likely  to  benefit  from  an  Intranet 
were  found.   The  basis  for  such  selection  was  determined  by  considering  the  population 
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affected,  frequency  of  use,  frequency  of  update,  mode  of  use,  and  other  concerns 
applicable  to  the  daily  functions  within  the  department.  The  processes  likely  to  benefit 
from  Intranet  implementation  are  listed  below  in  much  the  same  format  as  the  critical 
analysis  above: 

Course  Support 

Population:  Very  large  population 

Frequency  of  use:  High  frequency  during  scheduling  periods.  These  high 
frequency  times  are  the  last  few  weeks  and  first  two  weeks  of  each  quarter. 

Frequency  of  update:  Frequent  during  the  last  few  weeks  and  first  two  weeks  of 
each  quarter. 

Mode  of  use:  Multiple  Queries 

Concerns:  Need  for  current  data.  The  data  in  a  scheduling  database  must  be  kept 
current  at  all  times.  The  current  systems  information  is  not  kept  current  due  to  the  nature 
of  the  scheduling  process  and  environment.  The  Education  Technician  will  use  the 
database  for  planning  and  negotiating  with  the  NPS  schedulers.  Students  and  faculty  will 
want  the  data  to  be  accurate  and  reliable.  Because  of  the  changing  nature  of  the 
scheduling  process  (up  to  the  last  weeks  of  each  quarter)  the  data  could  never  be  entirely 
accurate.  Students  would  use  the  "fuzzy  data"  to  make  decisions  and  schedules  only  to 
be  disappointed  when  the  final  schedule  was  published. 

Thesis  Topic/Student/ Advisor  recording 

Population:  All  Students  and  most  if  not  all  of  the  Faculty 

Frequency  of  use:  Weekly 

Frequency  of  update:  Quarterly 
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Mode  of  use:  Single  Query  and  Multiple  updates 

Concerns:  Information  changes  throughout  the  thesis  process.  Currently,  there  is 
no  way  to  ensure  data  is  current  in  the  manual  files.  Frequently,  faculty  will  have 
discussions  with  the  department  chair  concerning  their  contributions  during  a  rated 
period.  The  Department  Chair  uses  the  database  to  evaluate  contributions. 

Course  Validation  tracking  and  reporting 

Population:  Moderate  use  by  Academic  Associates,  Curricular  Officer  and 
occasionally  students. 

Frequency  of  use:  Quarterly 

Frequency  of  update:  Quarterly.  The  majority  of  validation  occurs  in  last  weeks 
and  first  two  weeks  of  a  quarter. 

Mode  of  use:  Multiple  Queries  and  Single  Update 

Concerns:  The  current  manual  system  does  not  support  the  Education  Technician 
having  current  data.  The  information  is  maintained  in  the  curricular  office,  which  requires 
the  departmental  Education  Technician  to  physically  retrieve  the  data.  Currently,  the 
Department  Education  Technician  establishes  records  for  each  student  at  matriculation 
and  has  no  way  to  monitor  additional  validation.  Updates  to  a  duplicate  set  of  manual 
records  are  done  in  the  curricular  office,  the  departmental  records  are  not  kept  current. 

Student  Observation  Forms  (SOFS) 

Population:  Large  use  from  the  entire  student  body  and  all  teaching  faculty. 

Frequency  of  use:  Quarterly 

Frequency  of  update:  Quarterly 

Mode  of  use:  Single  Query  and  Multiple  Updates 
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Concerns:  The  current  system  requires  one  teaching  day  to  be  devoted  to  SOF 
administration.  An  Intranet  application  would  provide  cost  savings  for  Mark-sense 
forms  and  timesaving  for  processing  the  forms.  There  will  be  an  increase  in  the  turn- 
around time  to  the  instructor,  so  that  information  will  be  available  to  implement  well  in 
advance  of  the  next  quarter.  This  will  offer  the  faculty  a  more  efficient  use  of  this 
information.  There  is  also  a  concern  of  maintaining  and  ensuring  anonymity  of  all  forms 
from  both  the  student  and  teaching  faculty  standpoint.  The  concerns  surround  anonymity 
after  student  mark-up  and  privacy  of  written  comments  provided  by  students  and  given  as 
feedback  to  instructors. 

End  of  Course  Journals 

Population:  Faculty  use  only 

Frequency  of  use:  Quarterly 

Frequency  of  update:  Quarterly 

Mode  of  use:  Single  update  and  Multiple  Queries 

Concerns:  This  information  is  mostly  static.  Although  classes  are  taught 
repeatedly,  journals  are  maintained  as  historical  reference  for  classes.  This  data  can 
function  as  an  online  library  for  faculty.  Faculty  may  be  more  inclined  to  browse  the 
information  if  the  data  is  readily  available.  Human  nature  is  a  concern  as  an  online 
resource  is  more  likely  to  be  used  by  the  faculty  if  the  resource  is  available  when  they 
need  the  journal.  Having  an  online  resource  allows  faculty  to  prepare  for  classes  on  their 
own  schedule.  Course  Journals  will  potentially  be  more  current  if  the  update  and 
retrieval  is  online  and  real  time. 
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Thesis  Assessment  Reports 

Population:  All  Students  and  Faculty 

Frequency  of  use:  Quarterly 

Frequency  of  update:  Quarterly 

Mode  of  use:  Single  update  and  Single  query 

Concerns:  The  thesis  assessment  report  process  is  designed  as  a  data  gathering 
process.  The  information  is  used  only  to  track  and  evaluate  trends  in  theses.  Statistical 
evaluation  is  completed  by  manually  keying  in  scores  from  the  returned  assessments.  An 
online  form  would  automate  the  keying  and  filing. 

10.         Process  Impact  of  Implementation 

The  following  table  displays  a  subjective  score  of  each  process  considered  for 
prototyping  and  its  impact  for  implementation.  These  scores  were  validated  by  feedback 
received  from  department  faculty  and  administration  following  the  initial  prototype 
demonstration. 


Process 

Rank 

Scheduling 

8 

Thesis  Topic/Student/ Advisor  recording 

7 

Course  Validation  tracking  and  reporting 

6 

Student  Observation  Forms  (SOFs) 

7 

End  of  Course  Journals 

7 

Thesis  Assessment  Reports 

6 

Table  1:  Ranking  for  Intranet  Implementation  (Impact)*  1  =  Poor  -  10  =  Excellent) 
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The  table  ranks  the  impact  from  one  to  ten  with  one  being  poor  and  ten  being  the 
highest,  excellent.  Ranking  the  potential  impact  of  such  processes  allows  visualization 
and  a  mental  picture  of  how  efficient  and  effective  a  process  will  be  to  the  conduct  of 
daily  business  in  the  department  and  the  feasibility  of  migrating  such  a  process  on  line. 
Obtaining  a  subjective  score  of  less  than  five  would  indicate  that  the  process  would  not 
warrant  inclusion  as  part  of  the  prototype. 

The  impact  of  all  the  processes  are  all  above  average.  None  of  the  processes 
listed  are  currently  automated.  Any  automation  will  streamline  the  process,  improve  the 
amount  of  work  the  Education  Technician  can  accomplish  and  improve  accuracy.  The 
conclusion  is  to  implement  all  the  above  listed  processes  into  a  prototype. 

11.        Entity  to  Process  Relationship 

This  section  is  devoted  to  explain  the  relationship  that  an  entity  will  have  with  the 
selected  processes.  This  is  not  to  be  confused  with  the  database  entity  relationships 
where  entities  are  designated  as  one  to  one,  one  to  many,  or  many  to  many  relationships 
with  other  entities.  An  analysis  was  conducted  to  determine  how  the  process  will  impact 
the  user  and  content  providers,  the  tools  required  by  design,  plans  to  address  security 
related  issues,  and  the  roles  and  responsibilities  of  the  user  and  content  providers,  and 
miscellaneous  changes  and/or  enhancements  to  the  process  when  compared  to  the  current 
state. 

a.  Scheduling 

Impact  on  User:  There  are  no  special  viewers  or  tools  needed.    All  NPS 
faculty  and  students  have  access  to  the  WWW  at  least  through  the  public  Unix  terminals. 
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Additionally,  free  tools  and  utilities  are  readily  available  from  the  computer  center 
support  staff  within  the  department. 

Impact  on  Content  Providers:  Cold  Fusion  and  HTML  authoring  tools  are 
needed  on  the  Server.  No  special  Database  tools  or  applications  are  needed  once  the 
database  shell  is  built. 

Tools  Required  for  Design:  Website  Pro  and  Cold  Fusion  are  the  only 
tools  needed  for  this  process. 

Plans  to  address  security  related  issues:  Students  can  only  view  their 
schedule  and  a  generic  list  of  available  courses.  Academic  Associates  can  access  any 
student's  schedules.  Curricular  office  personnel  can  access  all  schedules.  The 
department's  Education  Technician  can  update  and  change  the  database  freely. 

Roles  and  Responsibilities  of  Content  Providers  and  Users:  The 
department's  Education  Technician  or  computer  systems  administrator  will  need  to  know 
how  to  administer  Cold  Fusion  Pro  and  Website.  Required  skills  will  include  adding 
users,  changing  permissions,  and  updating  and  creating  Cold  Fusion  templates. 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  This  will  allow  the  department's  Education  Technician  to 
view  the  quarter's  courses  from  a  browser  viewpoint  instead  of  a  database  design  view. 
This  enhances  posting  of  changes  instantaneously  without  the  delay  time  involved  with 
reprints.  Students  will  be  able  to  view  their  quarter  courses  and  other  available  courses 
in  a  snapshot.  An  online  version  will  allow  multiple  user  access  and  prevent  loss  of 
information  as  opposed  to  the  current  system  of  one  or  two  printed  course  listings  kept  in 
a  common  area  that  is  locked  during  non  business  hours. 


54 


b.  Thesis  Topic/Student/Advisor  recording 

Impact  on  User:  No  special  tools  required. 

Impact  on  Content  Providers:  Content  provider  will  be  the  collector  of 
information.  The  provider  will  no  longer  need  to  maintain  manual  files. 

Tools  Required  for  Design:  Website  Pro  and  Cold  Fusion  are  the  only 
tools  required. 

Plans  to  address  security  related  issues:  The  prototype  would  allow  access 
only  to  generic  statistics  to  uninvolved  parties  (NPS  students  only).  It  will  also  allow 
Academic  Associates  and  faculty  to  view  information  commensurate  to  their  positions. 
The  Department  Chair  will  have  unlimited  access. 

Roles  and  Responsibilities  of  Content  Provider  and  Users:  Maintain 
running  system  and  background  applications  (Cold  Fusion  and  Website). 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  The  prototype  would  eliminate  re-keying  of  data  and  the 
current  manual  file  system.  This  allows  for  creation  of  a  historical  database  with  broader 
access  and  will  now  fully  automate  the  process  through  an  online  format. 

c.  Course  Validation  Tracking  and  Reporting 
Impact  on  User:  No  special  tools  required. 

Impact  on  Content  Providers:  Database  application  will  be  necessary  to 
fully  realize  the  multiple  queries  and  reports  possible. 

Tools  Required  for  Design:  Website  Pro,  Cold  Fusion,  and  Microsoft 
Access  (database  application)  are  the  tools  needed. 
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Plans  to  address  security  related  issues:  Allow  only  the  Education 
Technician  to  make  changes  to  tables  and  data.  Allow  students,  Academic  Associates, 
and  Curriculum  Officers  to  view  data  in  various  formats. 

Roles  and  Responsibilities  of  Content  Provider  and  Users:  The 
department's  Education  Technician  must  update  points  of  contact  pertaining  to  the 
database  and  course  validation  requirements.  Course  Coordinators  must  update  course 
validation  requirements  as  needed. 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  Validation  testing  will  remain  a  manual  process.  The 
tracking  of  validation  credit  between  the  cunicular  office  and  the  department  will  be 
consolidated  allowing  both  to  have  current  information. 

d.        Student  Observation  Forms  (SOFs) 

Impact  on  User:  No  special  tools  required. 

Impact  on  Content  Providers:  No  special  tools  required. 

Tools  Required  for  Design:  Website  Pro  and  Cold  Fusion  are  the  only 
tools  needed. 

Plans  to  address  security  related  issues:  A  student's  anonymity  must  be 
ensured.  Students  are  limited  to  one  input  per  course  within  the  quarter  for  which  they 
are  currently  enrolled.  Faculty  access  must  be  restricted  until  after  grades  are  posted, 
furthermore  must  be  restricted  to  the  course  taught.  Faculty  are  restricted  from  making 
SOF  input.  Department  Chairs  may  have  unlimited  access  to  all  departmental  courses. 
Academic  Associates  restricted  to  area  commensurate  to  their  position. 
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Roles  and  Responsibility  of  Content  Provider  and  users:  The  department's 
Education  Technician  is  responsible  to  set  up  administrative  information  for  each  course, 
i.e.,  Course  Number,  Instructor,  SOF  Number,  and  Student  Participation. 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  The  department's  Education  Technician  will  maintain 
administrative  information.  The  prototype  will  allow  migration  of  the  entire  process 
from  a  manual  based  system  to  a  fully  automated  process.  This  eliminates  the  need  to 
use  class  time  for  the  administration  of  SOFs. 

e.        End  of  Course  Journals 

Impact  on  User:  No  special  tools  required. 

Impact  on  Content  Providers:  No  special  tools  required. 

Tools  Required  for  Design:  Website  Pro  and  Cold  Fusion  are  the  only 
tools  needed. 

Plans  to  address  security  related  issues:  Access  will  be  restricted  to 
Faculty  only,  with  no  student  interaction  possible. 

Roles  and  Responsibilities  of  Content  Provider  and  Users:  Faculty  will 
provide  the  Education  Technician  with  quarterly  updates  to  the  course  taught  in  a  specific 
quarter. 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  Currently  the  process  is  manual.  Providing  an  online 
format  will  enhance  the  efficiency,  effectiveness  and  use  of  these  journals.  The  online 
and  readily  available  format  will  encourage  faculty  to  use  and  update  the  journals  in  a 
timely  and  routine  manner. 
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f.         Thesis  Assessment  Reports. 

Impact  on  User:  No  special  tools  required. 

Impact  on  Content  Providers:  No  special  tools  required. 

Tools  Required  for  Design:  Website  Pro  and  Cold  Fusion  are  the  only 
tools  required. 

Plans  to  address  security  related  issues:  Access  will  be  limited  to  involved 
parties  and  departmental  leadership. 

Roles  and  Responsibilities  of  Content  Provider  and  Users:  Faculty  and 
students  must  submit  their  information  as  required  at  the  end  of  the  thesis  process. 

Miscellaneous  Changes  and/or  Enhancements  to  the  process  when 
compared  to  the  current  state:  The  current  system  is  completely  manual.  An  automated 
process  avoids  re-keying  and  will  support  the  development  statistical  analysis  of  the 
thesis  process. 

12.         Systems  Architecture  and  Design 

According  to  one  of  the  system  administrators,  all  Department  of  Systems 
Management  professors  have  some  form  of  computer  and  TCP/IP  access.  Systems 
include  Apple  Macintosh,  IBM  PC  or  compatible  or  Unix.  The  number  without  direct 
connections  is  very  small  and  all  instructors  will  be  able  to  directly  access  the  network  by 
the  end  of  Winter  1997  quarter  (March  1997),  after  implementation  of  the  new  network 
system  being  built  for  the  department.  Those  instructors  that  don't  have  direct  access  to 
the  network  can  connect  through  dial  up  connections.  Once  again,  this  will  not  be 
necessary  after  March  of  1997. 
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The  system  will  consist  of  client  machines  and  server  machines.  Datafiles  can 
exist  on  either  the  server  or  any  machine  on  the  network,  as  long  as  appropriate  access 
permissions  are  given  to  allow  access. 

The  client  machines  will  be  located  in  offices  of  faculty  and  staff  of  the 
department.  The  specific  software  required  for  a  client  is  minimal  and  will  be  discussed 
in  Chapter  IV.  Server  software  will  also  be  discussed  in  Chapter  IV. 

The  physical  location  of  a  machine  will  not  have  any  impact  on  the  functionality 
of  that  machine.  The  server  machine  should  be  provided  with  adequate  security  to 
prohibit  alteration  of  data  or  HTML  pages. 

On  the  server,  a  directory  structure  is  used  to  promote  both  maintenance  and 
security.  Figure  3  depicts  the  proposed  directory  structure  for  the  prototype.  All  folders 
are  located  under  one  working  directory,  wwwroot.  The  root  directory  is  further  broken 
down  into  subdirectories  associated  with  the  processes,  which  they  represent.  HTML 
pages  with  related  functions  are  kept  in  these  subdirectories.  Any  generated  data  and  the 
datafiles  are  also  kept  in  separate  subdirectories.  The  proposed  directory  structure  allows 
the  WWW  server  application  to  provide  much  of  the  necessary  security.  Access 
permissions  can  be  granted  based  on  directories  and  user  names  or  roles.  Data  security  is 
provided  by  the  security  functions  of  the  operating  system  of  the  server. 
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Figure  3:  Directory  Structure 
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IV.  INTRANET  DESIGN 

A.  INTRANET  TOOLS  AND  PROTOCOLS 

1.  Basic  Components 

The  components  of  an  Intranet  can  be  broadly  classified  as  either  client  or  server 
components.  In  some  cases  specialized  software  is  required  on  a  client  machine  to  support 
server  functions.  In  keeping  with  the  purpose  of  this  research,  the  prototype  was  designed 
to  function  with  "dumb  clients". 

The  applicable  technologies  are  Web  Servers,  Database  Servers,  Web  browsers  and 
the  TCP/IP  network  communication  protocol.  The  web  and  database  servers  handle  the 
interface  and  commands  necessary  to  interface  with  the  user  and  datasource.  The  Web 
Browser  handles  the  communications  between  the  user/client  and  the  Webserver.  The 
combination  of  the  web  server  and  the  browser  handle  all  of  the  information  formatting 
and  output  commands.  The  TCP/IP  protocol  is  the  standard  used  for  network 
communication  between  machines  and  programs  that  are  interconnected  through  any 
number  of  network  hardware  architectures. 

2.  Client 

A  client  machine  needs  to  have,  as  part  of  its  installed  operating  system  the 
necessary  protocols  for  communication  on  the  enterprise  network.  Most  Intranets,  since 
they  use  technologies  and  tools  developed  for  the  Internet,  use  the  TCP/IP  protocol. 
However,  proprietary  or  other  protocols  are  possible  since  the  Intranet  is  designed  to  serve 
internal  functions.  Protocols  other  than  TCP/IP  are  beyond  the  scope  of  this  thesis. 
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A  client  can  be  either  smart  or  dumb.  A  "smart  client"  is  one  that  receives  data  and 
information  in  a  raw  form  and  performs  some  processing  locally.  A  "dumb  client"  is  one 
that  receives  only  formatted  information  and  only  does  processing  necessary  to  output  the 
information. 

The  primary  benefit  of  a  "smart  client"  is  that  the  load  of  the  server  is  minimized. 
The  primary  drawback  is  that  applications  and  coding  is  more  sophisticated  and  therefore 
more  costly.  These  costs  involve  increased  development  time  and  financial  cost. 

As  stated,  a  "dumb  client"  is  a  client  that  does  not  process  the  information.  All 
processing  is  performed  at  the  server.  Clients  require  only  a  compatible  browser. 

The  benefits  of  "dumb  clients"  are  that  cost  of  development,  hardware  requirements 
and  user  training  are  all  kept  low.    The  drawback  is  that  the  server  assumes  the  entire 
processing  overhead,  so  users  will  perceive  some  latency  in  having  information  processed. 
3.    Server 

In  a  general  sense  the  Intranet  server  requires  some  software  to  format  and  deliver 
information  to  the  network  for  display  on  the  client  machine.  The  prototype  server 
developed  for  this  research  consists  of  a  WWW  server  and  an  ODBC  server. 

The  ODBC  server  processes  requests  for  data  by  executing  the  DBML  (Database 
Markup  Language)  commands  and  actually  interfacing  with  the  database  files.  The 
information  in  these  requests  is  formatted  in  the  HTML  pages  as  an  SQL  query.  The  SQL 
query  is  passed  to  the  ODBC  protocol  drivers  to  access  the  datafiles. 


Laudon,  Kenneth  C.  &  Jane  P.,  Essentials  of  Management  Information  Systems, 
Organizations  and  Technology,  Second  Edition,  Prentice  Hall,  1997  p  270. 
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The  datafiles  can  be  in  a  shared  directory  anywhere  on  the  network.  In  fact,  ODBC 
is  a  good  means  of  combining  data  from  multiple  locations  in  multiple  databases.  As  the 
ODBC  drivers  return  data,  the  ODBC  server  reformats  the  data  into  a  format  that  can  be 
transmitted  and  displayed  to  the  user  as  an  HTML  document.  The  ODBC  passes  this 
formatted  information  to  the  Webserver  to  pass  to  the  user. 

The  use  of  the  ODBC  protocol  allows  one  server  to  access  databases  designed  in 
different  database  front  ends.  For  example,  an  ODBC  request  can  be  sent  to  a  database 
built  with  Microsoft  Access  or  Borland  Paradox.  The  DBML  pages  allow  this  to  be 
handled  from  the  same  code  or  DBML  page.  The  commonality  of  code  allows  one 
application  or  collection  of  pages  to  access  data  in  multiple  databases  in  multiple  formats. 
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Figure  4:  Webserver  Architecture 


The  purpose  of  the  WWW  server  is  to  interface  with  the  network  and  receive  and 
manage  requests  for  information  stored  as  formatted  HTML  pages.  The  WWW  server  also 
functions  to  format  information  requests  in  a  manner  that  is  understandable  by  the  ODBC 
server.  As  information  is  pushed  to  the  network  the  ODBC  server  and  WWW  server  work 
together  to  publish  the  information  in  manner  consistent  with  the  HTML  protocol. 

Common  desktop  personal  computers  function  well  as  Intranet  Servers.  Webserver 
software  that  runs  on  desktop  personal  computers  using  desktop  operating  systems 
(Window  NT  Workstation  or  Windows  95)  is  readily  available  and  inexpensive.  These 
packages  are  well  supported  and  new  tools  are  released  almost  on  a  weekly  basis. 
Commercial  HTML  editor  programs  include  an  increasing  number  of  DBML  commands. 

B.  TOOL  SELECTION 

1.  Hardware 

The  hardware  that  was  used  for  the  development  of  the  prototype  can  be  classified 
as  "typical  desktop"  hardware.  The  development  platforms  were  a  486  and  Pentium  class 
machines.  The  use  of  two  machines  was  not  necessary.  Two  machines  were  used  only  for 
the  efficiency  provided  by  allowing  the  developers  unrestricted  access  to  a  workstation. 

An  evaluation  of  different  types  and  capabilities  of  software  and  hardware  is 
beyond  the  scope  of  this  research  and  is  left  as  a  recommendation  for  future  research. 
Benchmarking  or  testing  the  prototype  on  different  platforms  is  left  as  future  research  and 
will  be  discussed  in  Chapter  VI. 

A  test  of  the  server  running  using  the  two  different  machines  was  conducted.  One 
machine  consists  of  an  Intel  Pentium  166Mhz  CPU,  128  Megabytes  of  RAM,  2  Gigabytes 
of  hard  drive  capacity.     The  second  machine  is  a  Cyrix  486  DX2  80Mhz  CPU,  20 
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Megabytes  of  RAM  and  1 .2  Gigabytes  of  Hard  Drive  Capacity.  Both  machines  were 
connected  to  the  Department  of  Systems  Management  Local  Area  Network  (LAN)  via 
1 0Base2  Ethernet. 

The  test  consisted  of  running  a  query  to  retrieve  an  e-mail  address  from  the 
database.  Each  machine  had  a  copy  of  the  database  resident  on  the  hard  drive,  and 
therefore  did  not  have  to  compete  for  access  of  a  central  datasource.  In  order  to  have 
similar  network/environmental  conditions  the  query  action  button  was  pressed 
simultaneously  on  each  machine.  This  was  done,  as  much  as  possible,  to  ensure  similar 
network  traffic  conditions.  Since  Ethernet  is  a  collision  sensing  protocol,  the  authors  felt 
that  the  actual  query  and  result  message  from  the  server  for  each  machine  would  compete 
equally  for  a  transmission  slot  on  the  network. 

The  test  showed  that  response  from  the  Pentium  server  was  noticeably  faster.  The 
response  was  almost  immediate,  less  than  1  second  before  a  response  was  displayed.  The 
response  for  the  486  machine  was  noticeably  longer.  The  response  was  not  displayed  for 
20  seconds. 

2.         Software 

The  server  software  was  chosen  after  consideration  of  many  factors.  Multiple 
products  were  reviewed  by  three  groups  of  students.  The  server  applications  that  were 
evaluated  were;  Internet  Information  Server  (IIS)  by  Microsoft,  Website  by  O'Reilly  and 
Associates,  FastTrack  by  Netscape  Communications  and  Purveyor. 

The  criteria  used  for  the  evaluation  were;  Time,  Cost,  Hardware  and  Software 
Constraints,  Browser  Compatibility,  Database  Links,  Authoring  Tools,  Features, 
Scalability,  and  Administration. 
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Time  was  evaluated  on  the  basis  of  the  complexity  of  installation  and  the 
usefulness  of  the  documentation.  Cost  included  the  restrictions  on  client  platforms, 
licensing,  and  technical  support.  Hardware  and  software  constraints  included  an 
evaluation  of  minimum  requirements  and  cross  platform  compatibility.  Browser 
compatibility  was  simply  an  evaluation  of  which  browsers  were  supported.  Links  to 
database  evaluated  how  many  different  types  of  databases  are  supported,  whether  or  not 
the  interface  was  proprietary,  and  if  the  tools  are  included  with  the  server.  Authoring  Tools 
was  a  basic  check  to  evaluate  if  an  authoring  tool  was  included  that  would  assist 
developers  with  HTML  page  creation  and  linking  to  the  database.  Features  evaluated  if  the 
package  included  security,  e-mail,  ftp,  and  site  searching.  Scalability  was  a  check  to  see  if 
the  software  had  provisions  for  adding  components  or  capabilities.  Administration 
evaluated  whether  the  site  included  provisions  for  logging  activity  and  remote 
administration  capability. 


Microsoft 
Internet 
Information 
Server 

O'Reilly 
Website 

Netscape 
FastTrack 

Purveyor 

Time 

Cost 

Free         with 
Server 

$495 

$295 

$895 

Hardware          & 

Software 

Compatibility 

Windows  NT 
Server  Only 

Windows      95, 
Windows     NT 
Workstation 
and  Server 

Windows     NT 
Workstation 
and  Server 

Windows     NT 
Workstation 
and  Server 

Browser 
Compatibility 

All 

All 

All 

All 

Database  Links 

Yes 

Yes 

+$295 

+495 

Authoring  Tools 

Included 

Included 

Included 

Included 

Features 

Embedded 
FTP 

Freeware  FTP 
Add-in 

Freeware  FTP 
Add-in,  No  S- 
HTTP 

Freeware  FTP 
Add-in,  No  S- 
HTTP 

Scalability 

Yes 

Yes 

Yes 

Yes 

Administration 

Remote 

Remote 

Remote 

Remote 
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Microsoft 

O'Reilly 

Netscape 

Purveyor 

Internet 

Website 

FastTrack 

Information 

Server 

capable 

capable 

capable 

capable 

Table  2:  Web  Server  Capabilities 
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A  freeware  version  of  an  FTP  server  was  found  that  works  with  all  the  platforms. 
This  removed  FTP  as  a  discriminating  criterion. 

IIS  is  the  fastest  server.  The  researchers  were  not  able  to  determine  that  the 
performance  benefit  was  due  to  skewed  results  brought  on  by  the  hardware  that  the  tests 
were  run  on.  The  IIS  system  ran  on  server  hardware  consisting  of  128  MB  RAM  and  all 
other  web  servers  ran  on  client  hardware  consisting  of  32  to  64  MB  of  RAM. 

Even  though  IIS  is  a  free  program  (available  by  FTP  from  Microsoft  and  bundled 
with  Windows  NT  Server),  running  IIS  is  the  most  costly.  In  order  to  run  IIS  one  must 
have  Windows  NT  server  installed  as  the  platform  OS.  IIS  will  only  run  in  conjunction 
with  the  server  version  of  NT.  According  to  terms  of  the  end  user  license  agreement 
(EULA)  separate  licenses  must  be  purchased  to  use  NT  Server  as  a  webserver. 

The  basic  EULA  of  Windows  NT  Server  limits  connections  to  the  server  to  one 
connection.  Additional  licenses  can  be  purchased  on  either  a  per  server  or  a  per  seat  basis. 
The  per  server  option  is  a  means  to  purchase  licenses  for  a  set  number  of  concurrent 


23  Test  data  compiled  from:  Newman  and  Fowler,  "Web  Servers:  Digging  Into  Corporate 
Data",  Data  Communications,  pp57-68,  November  21,  1996,  and  http://website.ora.com 
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connections.  The  per  seat  license  is  owned  by  the  connecting  user.  If  per  seat  licensing  is 
used  the  client  must  have  a  license  for  each  server  they  will  connect  to. 

The  EULA  for  Windows  NT  workstation  limits  the  number  of  connections  to  ten. 
The  EULA  for  Windows  95  specifically  states  that  there  is  no  limit  to  the  number  of 
connections  if  the  product  is  used  as  a  network  server. 

IIS  had  the  fastest  performance  scores  when  working  with  the  database  and 
supported  all  the  listed  criteria.  IIS  is  the  only  package  that  includes  an  FTP  server 
capability  integrated  with  the  web  server. 

Netscape  FastTrack  does  not  support  Windows  95  as  a  Server  OS.  FastTrack  does 
not  include  a  database  server,  although  one  can  be  purchased.  FastTrack  does  not  include 
the  capability  for  secure  hypertext  transport  protocol  (S-HTTP).  FastTrack  was  the  lowest 
cost  of  all  the  Servers  evaluated.  The  key  discriminator  against  FastTrack  was  the  lack  of 
a  database  connection. 

O'Reilly's  Website  included  support  for  all  the  evaluation  criteria  and  capabilities. 
Website  is  compatible  with  Windows  95  and  all  versions  of  Windows  NT.  The  cost  for 
Website  was  equal  to  the  average  cost  of  all  the  packages  evaluated. 

Netscape  and  Purveyor  were  eliminated  from  the  selection  process  because 
Website  met  or  exceeded  them  in  all  categories.  Microsoft  Internet  Information  Server 
was  not  selected  because  IIS  will  only  run  with  Windows  NT  Server.  The  research 
involved  developing  a  prototype  that  would  integrate  easily  into  the  department  selected 
for  analysis. 

Eliminating  IIS  because  the  program  requires  Windows  NT  Server  may  seem 
overly  constraining.  One  can  argue  that  the  user  interface  is  the  same  for  Windows  95  and 
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Windows  NT  version  4.0.  One  of  the  prototype  design  goals  was  to  develop  a  system  that 
can  run  on  as  many  platforms  as  possible.  Additionally,  this  decision  was  made  to  avoid 
some  of  the  administration  overhead  associated  with  the  server  version  of  NT  and  to 
capitalize  on  the  permissive  nature  of  Windows  95. 

Permitting  Windows  95  as  a  target  system  allows  for  lower  deployment  costs. 
Also,  by  design,  Windows  95  is  more  tolerant  of  older  applications.  This  will  allow  many 
of  the  legacy  applications  to  continue  to  be  used.  Additionally  the  increased  cost  of 
Windows  NT  Server  and  additional  licenses  to  allow  multiple  client  access  to  the  web 
server  increased  the  cost  of  the  Windows  Server  and  IIS  package  well  beyond  the  cost  of 
Windows  and  O'Reilly  Website. 

C.  USEFUL  RESOURCES 

Directed  study  in  Webserver  installation,  operation  and  maintenance  was  very 
helpful  in  developing  skills  necessary  for  development  of  WWW  interfaces  for  information 
sharing.  Understanding  the  capabilities  and  limitations  of  the  various  web  server 
applications  was  invaluable. 

Additional  exercises  and  directed  readings  in  WWW  based  content  development 
and  implementation  tips  and  techniques  also  helps  in  design.  Information  on  articles  and 
resources  is  contained  in  the  bibliography. 

The  following  resources  are  particularly  helpful  for  developing  concept  and  vision 
for  an  Intranet  project. 

Levitt,  Lee,  "Intranets:  Internet  Technologies  Deployed  Behind  the  Firewall  for 
Corporate  Productivity",  prepared  for  Internet  Society  INET'96  Annual  Meeting  (URL 
http://www.process.com/intranets/wp2.htp,  1 996). 
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PC  Week  Magazine  maintains  an  Archive  of  articles  and  case  studies  pertaining  to 
Intranets.  http://www8. zdnet.com/pcweek/builder/ibpast.html 

An  article  on  ROI  and  cost  benefit  analysis  of  Intranets  can  be  found  at: 
http://www.cio.com/WebMastera/040 1 97  roi.html 
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V.  IMPLEMENTATION  ISSUES 

A.  COST 

Implementation  of  an  Intranet  to  support  administrative  functions  in  the 
department  requires  the  purchase  of  webserver  software.  Additionally  it  is  recommended 
that  hardware  also  be  purchased  to  serve  as  a  server.  Discussion  of  actual  costs  is  used  to 
illustrate  expected  costs  and  to  serve  for  planning  purposes.  The  reader  should  keep  in 
mind  that  the  goal  was  to  develop  a  thesis  to  demonstrate  Intranet  capabilities,  not 
propose  a  target  configuration  or  components.  The  prices  are  for  actual  products  and  are 
current  at  the  time  the  thesis  is  written.  As  shown  in  Chapter  IV,  most  of  the  available 
software  is  priced  within  a  range  of  $50  of  any  competing  product. 

As  stated  in  Chapter  IV,  the  required  software  is  a  Webserver  and  an  ODBC 
database  server.  The  commercial,  off  the  shelf,  cost  for  the  Webserver  used  for  this 
prototype  is  $495.  There  are  two  versions  of  the  ODBC  available  commercially.  The 
workgroup  edition  ($495)  supports  databases  built  with  Microsoft  Access,  Microsoft 
Foxpro,  Borland  Paradox,  and  Borland  dBase.  The  professional  edition  ($995)  supports 
all  ODBC  databases. 

The  only  costs  associated  with  training  will  be  the  wages  or  salary  of  the 
individual  receiving  the  training.  There  is  no  cost  for  the  actual  training  since  one  of  the 
authors  will  be  available  conduct  the  training.  It  is  recommended  that  consideration  be 
given  to  allow  independent  study  or  directed  study  credit  be  given  to  the  trainer,  so  that 
time  can  be  allowed  in  his  academic  program. 
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B.  TRAINING 

As  stated,  training  can  be  conducted  by  one  of  the  authors.  This  is  possible 
because  one  of  the  Authors  will  remain  as  a  student  at  NPS  for  two  quarters  after  this 
thesis  is  completed. 

Having  the  student  available  after  thesis  competition  and  implementation  of  the 
system  allows  that  student  to  provide  support  for  implementation  and  further  refinement 
of  the  user  interface. 

It  would  be  impractical  to  have  regularly  scheduled  training  for  students  since 
there  is  a  constant  rotation  of  the  student  body.  A  more  feasible  approach  is  to  develop  a 
user  manual  designed  for  students  that  discusses  the  security  aspects  and  capabilities  of 
the  Department  Intranet. 

On  the  other  hand  current  faculty  and  staff  can  be  offered  a  one-time  training 
period.  Providing  opportunity  to  the  faculty  and  staff  will  help  the  system  be  accepted  in 
the  department.  The  administrator,  as  needed  can  conduct  training  of  new  personnel. 
However,  a  more  efficient,  informal  training  by  peers  will  probably  become  the  norm  as 
individuals  will  strive  to  minimize  the  time  needed  away  from  their  primary 
responsibilities. 

The  system  administrator  will  need  more  extensive  training.  Depending  on  the 
experience  and  skills  of  the  individual,  training  in  HTML  and  database  management  may 
be  necessary.  At  a  minimum,  the  system  administrator  will  need  training  in  the  security 
and  operation  aspects  of  the  specific  Webserver  software. 
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C.  SECURITY 

Security  is  best  understood  by  understanding  the  types  of  users  and  what 
information  they  will  need  to  access.  The  types  of  users  for  this  system  are  Students, 
Faculty,  Staff,  Department  Administration,  and  the  system  administrator. 

There  are  only  a  few  areas  that  have  information  relevant  to  students.  Students 
have  a  need  for  administrative  contact  information  about  Faculty,  such  as  office  and 
email  address.  Students  also  may  be  interested  in  what  classes  are  offered  in  a  particular 
quarter  and  what  texts  have  been  requested.  Also,  students  will  use  the  system  to  submit 
SOF  input. 

Faculty  information  needs  are  similar  to  students  and  include  a  few  others. 
Faculty  will  also  use  the  system  to  complete  course  journals  and  requisition  textbooks. 
Faculty  will  also  receive  SOF  information  through  email  generated  by  the  system. 

Department  staff  will  have  a  need  for  some  of  the  faculty  contact  information. 
Additionally  the  staff  will  use  the  system  for  viewing  departmental  news  and  messages 
that  are  not  distributed  using  email  or  other  means. 

Department  administrators  will  access  SOF  reports  as  well  as  the  information 
used  by  the  other  classes  of  users.  As  a  business  rule,  department  administration  should 
be  prevented  by  viewing  confidential  SOF  comments  between  students  and  instructors. 

As  stated,  the  system  administrator  will  need  to  have  access  to  all  the  information. 
This  is  necessary  for  the  performance  of  maintenance  and  for  some  other  administrator 
tasks,  such  as  dispatching  SOF  comments  to  instructors  when  directed. 

An  important  security  feature  that  should  be  used  is  logging.  NPS  computer 
security  rules  require  logging  by  all  machines  that  can  be  accessed  by  or  allow  access  to 
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the  campus  networks.  Logging  involves  the  automatic  recording  of  who  access  the 
system.  The  existence  of  logs  is  important  if  information  needs  to  be  restored  or  breeches 
need  to  be  investigated.  The  log  provides  a  means  of  identifying  what  users  or  office 
accessed  what  portion  of  the  system. 

In  addition  to  assigning  users  to  different  classes,  as  allowed  by  the  webserver, 
files  should  be  segregated  within  the  file  structure  for  the  server.  Setting  up  a  directory 
structure  that  groups  related  HTML  pages  and  content  allows  the  administrator  to  assign 
permissions  and  manage  security  each  file  directory.  This  security  scheme  will  facilitate 
the  publishing  of  information.  For  example,  newsletters  and  messages  can  be  stored 
together  in  a  relatively  accessible  directory.  This  allows  the  creator  of  the  information  to 
publish  directly  to  the  server  with  rninimal  input  from  the  administrator.  Conversely, 
items  such  the  database  and  SOF  comments  should  be  in  secured  directories  so  the 
integrity  of  the  information  can  be  insured. 

D.  DATABASE  POPULATION 

There  are  two  methods  of  getting  information  into  the  database.  The  first  method 
is  to  allocate  a  person  or  group  of  persons  to  the  task  and  have  them  type  in  relevant 
information,  such  as  classes,  instructors  and  newsletters.  After  the  initial  information  is 
input,  as  the  system  is  used  information  will  remain  current.  The  second  method  is  to 
operate  the  Intranet  in  parallel  with  the  current  manual  system,  until  such  a  point  that  the 
database  has  caught  up  with  the  manual  system.  Even  with  this  method,  a  certain  amount 
of  raw  data  that  does  not  change  on  a  frequent  basis  will  need  to  be  input  into  the 
database. 
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Some  data  can  be  imported  directly  from  the  prototype.  The  faculty  information 
contained  in  the  prototype  database  is  actual  and  current.  No  SOF  information  needs  to 
be  input,  since  the  information  is  new  every  quarter.  As  the  system  is  used  the  SOF 
protion  of  the  database  will  grow  and  provide  more  information  on  trends,  as  more 
historical  information  is  available. 

E.  DATABASE  ADMINISTRATION 

The  system  administrator  should  be  given  responsibility  and  ownership  of  the 
database.  Due  to  limitations  imposed  by  linking  to  the  data  through  an  ODBC  server, 
access  to  pages  that  change  or  to  the  actual  datafiles  should  be  restricted. 

In  order  to  change  the  data  in  the  database,  requests  should  be  sent  to  the 
administrator.  HTML  pages  have  been  built  in  the  prototype  that  demonstrate  the  ability 
to  modify  records  from  the  browser  window. 

One  feature  demonstrated  in  the  prototype  is  the  ability  to  notify  individuals  of 
changes  to  information.  As  a  change  is  committed,  the  webserver  will  send  a  message 
that  shows  what  information  was  changed.  This  feature  was  implemented  as  a  means  of 
checking  the  accuracy  of  information.  If  the  user  receives  verification  e-mail,  then  the  e- 
mail  address  on  file  is  correct,  if  not,  the  administrator  will  receive  a  message  from  the  e- 
mail  daemon,  this  is  an  indication  that  the  e-mail  address  is  incorrect.  Upon  receipt  of  the 
e-mail,  the  user  has  the  responsibility  of  verifying  the  information. 

As  stated  earlier,  newsletters  or  information  for  all  users  can  be  published  to  the 
Intranet  directly  from  the  originator.  Most  word  processors  include  the  ability  to  save  a 
document  as  an  HTML  document.  Additionally,  ASCII  text  documents  can  be  viewed 
from  any  WWW  browser. 
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VI.  SUMMARY 

A.  PROJECT  CONCLUSIONS 

1.  Intranets  vs.  Internets 

Basically  an  Intranet  is  a  collection  of  technologies  that  are  common  to  the 
Internet  to  publish  and  share  information  within  an  organization  amongst  organization 
employees  rather  than  sharing  or  providing  information  to  the  general  public.  What 
distinguishes  an  Intranet  from  an  Internet  is  the  application  itself.  Intranets  are 
personable  and  are  developed  and  used  for  and  within  organizations.  Intranets  focus  on 
employees.  By  design  they  are  process  oriented,  provide  an  environment  for  employees 
to  streamline  how  work  is  done  and  how  to  expedite  the  creative  and  developmental 
processes.24  Internets  on  the  other  hand  are  not  personable,  rather  they  are  designed  for  a 
specific  group  of  users,  but  public  information.  Internets  focus  primarily  on  company 
profiles  and  product  orientation,  making  them  an  excellent  source  for  educational 

Oft 

research  for  their  intended  audience,  the  consumer,  the  customer,  and  the  student. 

2.  The  Prototype  System  as  a  Development  Tool 

Prototypes  are  playing  an  increasing  role  in  product  and  process  design.  Rapid 
prototyping  can  help  in  saving  time  and  money.  It  serves  as  a  tool  for  user  change  and 
allows  for  the  delivery  of  a  workable  system  as  an  end  product.  The  significance  in 


24  Hinrichs,  Randy  J.,  Intranets:  What's  the  Bottom  Line?,  Prentice  Hall  Computer 
Books,  p.  33,  June  1997. 

25  Ibid.  p.  34. 

26  Ibid.  p.  32. 

27  Colton,  Jonathan,  Eastman,  C,  Graver,  T.,  Ku,  D.,  Kurfess,  T.,  McGinnis,  L., 
Farrokh,  M.,  Muzzy,  J.,  Rosen,  D.,  Schwerzel,  R.,  and  Starr,  T.,  "Rapid  Prototyping  and 
Manufacturing  at  Georgia,  Tech",  white  paper,  p.  2.,  28  June  1996. 
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contributions  to  cost/time  reduction  and  functional  improvement  in  the  product 
realization  process  as  it  applies  to  information  technology  management,  is  really  no 
different  than  developing  the  physical  artifact  for  a  manufacturing  process.28  The 
resulting  Intranet  product  is  useful  for  visualization,  interference  checking,  and  functional 
testing.  Prototypes  being  developed  with  today's  technology  are  workable,  useable,  and 
fully  functional  systems.  It  does  not  make  sense  any  longer  to  spend  the  necessary  time 
and  money  in  developing  a  rapid  prototype,  only  to  throw  it  away.  Intranet  prototypes  can 
be  placed  in  the  same  category  as  other  physical  developmental  products;  they  can  be 
immediately  used  after  development  and  testing. 

3.    The  IDM  Tool 

This  thesis  has  been  an  excellent  candidate  in  demonstrating  and  proving  that  the 
traditional  systems  development  lifecycle  (SDLC)  process  is  now  obsolete.  The  modified 
IDM  methodology  for  development  of  this  prototype  provided  a  means  to  work  in 
manageable  modules,  build  a  rapid  prototype,  modify  the  prototype  when  needed  through 
continuous  testing,  and  to  stress  the  user  interface,  which  are  all  key  characteristics  of 
building  rapid  prototypes.30  This  methodology  proved  specific  enough  to  analyze  this 
topic,  but  is  easily  adaptable  and  can  be  applied  to  any  system  analysis  problem. 


28  Ibid.,  p.  2. 

29  Ibid.,  p.  3. 

0  Kenndall,  Kenneth  E.  and  J.E.  Kenndall,  Systems  Analysis  and  Design,  3rd 
edition,  p.  214,  Prentice  Hall,  Englewood  Cliffs,  New  Jersey,  1995 
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B.  AREAS  FOR  FURTHER  RESEARCH 

1.    Limitations  of  and  Enhancements  to  the  Prototype 

Security  will  continually  be  an  issue.  Remote  user  initial  login  is  not  physically 
present  in  the  prototype.  Users  do  not  have  the  capability  to  access  and  request  a  login 
and  password.  Users  must  be  manually  entered  into  the  database,  through  the  use  of 
Intranet  based  forms  by  the  administrator. 

Another  issue  is  limiting  the  number  of  SOFs  that  a  student  can  access.  If  a 
student  wanted  to  fill  out  several  SOFs  for  one  class,  he/she  could  do  so.  This  is  not  to 
say  that  the  administrator  could  not  limit  the  number  of  SOF  forms  being  distributed  per 
class.  This  could  be  accomplished  through  software.  The  ultimate  problem  is  limiting 
accessibility  to  one  form  per  student,  while  at  the  same  time  providing  anonymity. 
Software  fixes  for  this  limitation  were  not  available  at  the  time  this  research  was 
conducted.  Future  technology  enhancements  lie  in  integrating  other  technologies  such  as 
JAVA  and/or  Active-X  into  a  user  database.  A  more  current  release  of  Website  has  the 
capability  to  link  with  the  actual  NT  server  for  access,  and  again,  was  not  available  at  the 
time  this  prototype  was  being  built. 

The  SMIDSS  prototype  will  enhance  the  daily  business  activities  within  the 
Department  of  Systems  Management  and  continue  maturity  through  use.  The  online 
browser  format  allows  easy  access  by  any  user.  The  Education  Technician  can  easily 
perform  any  job  functions  directly  from  the  desktop,  as  opposed  to  being  away  from  the 
desk  obtaining  paperwork  from  departmental  staff.  Constant  use  of  the  prototype 
promotes  continuous  and  iterative  change  through  user  feedback.    Users  will  have  the 
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ability  to  contact  the  Administrator  to  suggest  any  changes  or  enhancements,  thereby 
fulfilling  one  of  the  goals  of  the  IDM  process,  constant  improvement. 

2.    Campus  Wide  Implementation  Issues 

A  fundamental  issue  for  this  prototype  is  scaling  it  to  fit  the  needs  of  each 
department  at  NPS.  Although  not  an  issue  that  will  plague  migration,  each  department 
has  its  uniqueness.  The  use  of  the  modified  IDM  process  in  conducting  systems  design 
and  analysis  yielded  such  detailed  research,  that  modifying  processes  will  be  an  easy  task 
for  further  researchers. 

Security  for  the  Intranet  must  be  focused  on  the  confidentiality  of  the  SOFs. 
Policies  will  have  to  be  developed  defining  acceptable  use  and  communicating  security  to 
users.  Pending  campus-wide  implementation,  a  standard  security  protocol  will  have  to  be 
developed  to  ensure  uncompromising  success  in  maintaining  anonymity. 

Connectivity  to  the  registrar's  office  offers  another  hurdle  to  future  researchers. 
Software  rather  than  hardware  connectivity  is  the  problem.  Currently,  there  is  not  a 
foreseeable  fix  to  developing  a  fully  automated  scheduling  process,  therefore,  a  standard 
campus-wide  database  management  system  must  be  implemented.  A  database  would 
allow  mass  storage  of  classes,  faculty  and  students,  which  can  be  easily  maintained  and 
manipulated.  Although  not  an  algorithm  for  the  scheduling  process,  this  system  would 
allow  each  department  access  to  needed  information  and  provides  a  standard  for  software 
connectivity. 

SMIDDS  was  extensively  tested  for  implementation  within  the  confines  of  a 
single  department.   Further  research  into  a  testing  methodology  suitable  for  larger  scale 


80 


projects  (campus- wide)  to  include  concurrent  access,  must  be  pursued  to  understand  and 
fully  document  limitations  on  servers,  ODBC  serves,  and  various  hardware  components. 

3.    Migration  to  Military  Applications 

Since  late  1996,  the  Department  of  Defense  has  been  making  strides  to  move 
away  from  ARPAnet  to  the  Intranet  in  linking  legacy  Internet  and  Intranet  applications.31 
Intranets  are  proving  their  worth  because  of  open  standards-base  protocols,  thereby 
preserving  already  existing  hardware  and  software  applications.  The  military  as  a  whole 
must  understand  the  feasibility  of  developing  Intranets  for  its  daily  use.  No  longer  is  this 
tool  simply  connecting  technology  with  software,  but  serves  as  an  intelligence  tool. 
Putting  organizations  on  Intranets  allows  one  to  leverage  the  intelligence  of  that 
organization.  Downsizing  the  military  only  strains  organizations.  Military  service 
members  are  asked  to  do  and  know  more  with  fewer  resources.  Intranets  in  the  business 
world  can  be  applied  to  the  military  by  providing  a  means  to  define,  so  that  people  can 
focus  more  clearly  on  what  their  own  contributions  are  to  the  organization. 

The  cost  savings  realized  through  Intranets  will  come  in  the  form  of  time. 
Specifically,  this  is  time  taken  from  wartime  training  and  missions  spent  on 
administrative  and  decision  making  functions.  Intranets  will  allow  sharing,  managing, 
and  publishing  information,  as  well  as,  decision  making  from  any  desktop  by  linking  all 
information  within  an  organization.  The  focus  of  the  military  services  must  be  to  realize 


31  Barksdale,  J.,  "From  ARPAnet  to  Intranet:  The  U.S.  Government  and  Internet 
Technologies", 

http://home.fr.netscape.conVcomprooVcolumns/mainthing/govemmental.html,     Netscape 
Communication  Corporation,  28  September  1996. 

32  Hinrichs,  Randy  J.,  Intranets:  What's  the  Bottom  Line?,  Prentice  Hall  Computer 
Books,  p.  15,  June  1997 
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the  potential  of  Intranets.  Recognizing  this  investment  will  lend  itself  to  getting  usable 
information  in  the  hands  of  the  lowest  ranking  military  service  member  (empowered 
individual).  This  will  make  service  members  more  efficient  and  knowledgeable  in  the 
operations  of  an  organization  and  ultimately  provide  increased  time  to  conduct  wartime 
training  and  missions  in  an  era  when  time  is  a  commodity. 

Developing  this  prototype  proves  that  this  technology  can  be  easily  migrated  to 
similar  military  applications.  The  hardware  and  software  are  in  place  in  most 
organizations,  as  well  as,  the  network  connectivity.  Most,  if  not  all,  military 
organizations  are  using  email  to  communicate.  These  organizations  are  no  different  than 
commercial  businesses  in  respect  to  the  need  for  information  and  the  ability  to  control 
and  use  it.  However,  the  limiting  factor  in  military  organizations  is  expertise  to  migrate 
these  technologies  into  the  work  place.  There  are  not  any  Information  Officer  billets  or 
positions  in  place  within  military  organizations  below  Division  level  with  respect  to  the 
Army  and  similar  organizations  in  the  sister  services. 

The  benefits  of  an  Intranet  to  military  organizations  are  enormous.  Online 
training  through  video  and  scheduling  can  be  conducted  from  the  desktop.  The  Intranet 
can  be  a  learning  system  to  trainers  and  supervisors  as  they  look  to  other  organizations  to 
tap  into  experts  and  points  of  contact  to  provide  information.  It  is  a  knowledge  base 
system  for  leaders  and  supervisors  to  make  timely  and  informed  decisions. 

As  the  military  moves  toward  further  decentralization  of  its  units,  empowerment  of 
individuals  becomes  an  issue  and  a  goal.  Intranets  are  an  empowering  tool.   Being  able 


33  Ibid.,  pp.  152-153. 
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to  build  and  distribute  information  online  is  efficient  empowerment.34  Although  sharing 
information  is  a  risk,  service  members  cannot  possibly  be  responsible  for  improving  their 
processes,  improving  workflow,  and  collaborating  with  the  right  people  without  the 
needed  information.  One  of  the  risks  in  sharing  information  is  the  responsibility  and 
accountability  for  the  integrity  of  the  data.  Another  aspect  is  ensuring  that  the  information 
is  only  accessible  by  authorized  personnel.  Perhaps  the  greatest  benefit  will  be  for  those 
in  the  lower  ranks.  When  a  commander  publishes  a  vision,  values,  objectives  and  goals 
they  enhance  trust  and  provide  personnel  with  direction. 


34  Ibid.,  p.  159. 
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NAVAL  POSTGRADUATE  SCHOOL 
Monterey,  CA   93943-5000 


NPS (SM/FA) 
95 

MEMORANDUM 

From:   Chairman,  Department  of  Systems  Management 
To:     Curricular  Officers/Academic  Associates 
Department  Chairman 

Subj:   COURSE  OFFERINGS,  QUARTER  1996 

1.   The  following  courses  will  be  offered  by  the  Department  of 

Systems  Management  for  the  quarter  (beginning  Monday,  

1996)  : 


2.   The  following  courses  will  not  be  offered  during  the 
quarter: 


GAIL  FANN  THOMAS 

Associate  Chair  for  Instruction 

Systems  Management  Department 


Dist:   Codes  30,  31,  32,  33,  34,  35,  36,  37,  38,  39 

Codes  CS,  MA,  SM/Js,  SM/Et,  SM/Ev,  SM/Fa,  SM/Hc, 
SM/Hr,  SM/Lt,  SM/Mo,  SM/Mp,  SM/Sa,  SM/Th,  OR,  NS,  PH,  EC, 
MR,  AA,  OC,  ME,  AW,  SP,  EW,  CC 


Figure  B-l:  Course  Offering  Memorandum 
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NPS (SM/Fa) 
96 


MEMORANDUM 


From:   Gail  Thomas,  Associate  Chair  for  Instruction 
To: 

Subj  :   TEACHING  ASSIGNMENT  FOR  QUARTER,  AY  1997 

1.   During  the  coming  Quarter,  you  are  scheduled  to  teach 

the  following  course (s) : 

Course       Credit     Tentative 

Number        Hours      Enrollment      Segments 


Please  coordinate  your  textbook  selection  with 
.  who  will  also  be  teaching  the  course. 

2.  Do  you  want  1  or  2 -hour  class  meetings  for  ... 

___________      1  hour      '     2  hours  _ 

1  hour  2  hours  _ 


Do  you  need  a  scheduled  final  exam  for 
___________       Yes  _____     No  . 

Yes  No  _ 


**IF  UNSCHEDULED  EXAM,  WHAT  IS  YOUR  SUBSTITUTE?** 


4.   Please  indicate  any  specific  classroom  requirements  by  course 
number  below. 

CLASSROOM 
COURSE  NO.  REQUIREMENTS 


Figure  B-2:  Teaching  Assignment  Memo  -  Page  1 
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5.  Please  give  specific  reasons  to  justify  schedule  recruiremenfrp. 
When  listing  requirements,  it  is  important  that  you  specify  the 
days /times  that  you  CANNOT  teach. 


6.  LAB  SESSIONS  USING  1-158,  1-224,  1-250,  OR  I-364E  MUST  BE 
ASSIGNED  THROUGH  THE  SCHEDULER.  PLEASE  INCLUDE  AN?  SUCH  REQUIRE- 
MENTS BELOW  AS  WELL. 

1-158  1-224  1-250  I-364E 


7 .  What  software  do  you  want  available  in  the  Labs?  (Please  do 
not  list  software  that  is  already  installed.)  For  refer- 
ence, a  list  of  currently  installed  software  is  posted  outside  each 
lab. 


Do  we  have  the  software  that  you  have  requested  above?  Yes/No 

8.  TEXTBOOK  ORDER  FORMS 

Attached  is  a  textbook  order  form  for  each  course  listed  above. 
Please  return  this  order  form  to  Lvnn  Bovle.  even  if  vou  are  not 
ordering  any  textbooks.  Be  sure  to  show  the  ISBN  number  for  each 
text  ordered  and  the  exact  edition  you  want  if  not  the  latest  out 
on  the  market.  The  Bookstore  will  not  accept  the  order  without  it. 
NOTE:  The  bookstore  will  no  longer  order  optional  textbooks 
without  a  list  of  student  names  submitted.  This  usually  can't  be 
done  until  classes  have  started.  PLEASE  PRINT  YOUR  NAME  ON  THE 
TEXTBOOK  ORDER  FORM. 

9 .  RETURN  BOTH  OF  THESE  FORMS  TO  LYNN  BOYLE  NO  LATER  THAN  4;00 
P.M.  Monday,  29  April  1996. 


GAIL  FANN  THOMAS 


Figure  B-3:  Teaching  Assignment  Memo  -  Page  2 
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SPECIAL  NCTESt 


INSTRUCTOR'S  SIGNATURE 


DATE 

0  A  T  E 


1  6  :  5  3  :  .??   0  7     0  C  T  1 9  9  6 


Figure  B-5:  Textbook  Requisition  Form 
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11  JAN  95 
MEMORANDUM 

To:  All  SM  Faculty  Teaching  During  Winter  Quarter 

From:       Gail  Thomas,  Associate  Chair  for  Instruction 

Subj:         SUBMISSION  OF  Winter  1995  COURSE  JOURNALS/THESIS  QUALITY 
ASSESSMENT  FORMS 

1 .  For  those  who  taught  during  the  Winter,  please  submit  your  completed  course  journals  as 
soon  as  possible.  If  you  did  not  change  your  course  since  a  previous  complete  journal 
submission,  just  complete  a  new  cover  sheet  indicating  grade  distribution  for  Winter  quarter  and 
reference  the  prior  course  journal  in  the  comments  section. 

2.  Additionally,  Thesis  Quality  Assessment  forms  for  Winter  quarter  graduating  students  are 
being  distributed  for  your  completion  to  all  thesis  advisors  (if  you  need  more  forms,  see  Lynn). 
Please  submit  your  assessment  questionnaire(s)  to  Lynn  as  soon  as  completed.  Thanks. 


GAIL  FANN  THOMAS 


Figure  B-6:  Course  Journal  Instruction  Memo 
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24  JUN  96 
MEMORANDUM 

FROM:   Gail  Thomas,  Associate  Chair  for  Instruction  (Code  SM/Fa) 
TO:     1~ 

Subj  :   RETURN  OF  THE  THESIS  QUALITY  ASSESSMENT  SURVEY  FORMS 

1.  Please  return  the  completed  Thesis  Quality  Assessment  Survey 
Forms  for  the  student  theses  listed  below.  To  compile  the  results, 
we  would  like  the  forms  returned  to  us  by  COB  12  July  1996. 

2 .  The  student  theses  listed  below  are  what  we  currently  show  in 
the  database.  If  you  find  any  discrepancies  (student  names,  role, 
or  graduation  date) ,  please  correct.  In  any  case,  return  the  memo 
to  Lynn. 

3.  Your  cooperation  in  this  matter  will  be  greatly  appreciated. 


GAIL  FANN  THOMAS 

Faculty       Advisor      Student         Curriculum  Grad  Otr 
1-  2-  3-  4-  5- 


TP  =  Principal  Advisor 

TC  =  Co-Advisor 

TA  *  Associate  Advisor 


Figure  B-7:  Thesis  Quality  Assessment  Transmittal  Memo 
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SYSTEMS  MANAGEMENT  DEPARTMENT 

THESIS  QUALITY: 
ADVISORS'  ASSESSMENT 


As  part  of  our  efforts  to  get  better  information  on  how  we're  doing  in  our  core 
instructional  activities,  we  are  initiating  a  simple  assessment  effort  focused  on 
assessing  the  "quality"  of  our  students'  theses.  To  mat  end,  we're  asking  each 
"advisor"  (principal  advisor,  co-advisor,  associate  advisor)  to  complete  the 
following  brief  questionnaire  on  each  thesis  mat  he  or  she  signs.  The  purpose  of 
the  questionnaire'  is  to  provide  all  of  us  (Systems  Management  faculty)  with  a 
more  complete  picture  of  what  we  think  about  the  value  of  the  theses  we  are 
involved  with.  Our  collective  views  should  be  interesting,  at  the  least,  and  more 
importantly,  indicate  how  we're  doing  and  suggest  where  and  how  we  can 
improve  in  making  the  thesis  a  valuable  educational  experience  that  contributes  to 
bom  our  students'  future  career  success  and  helps  DoD  more  effectively  address 
its  current  and  anticipated  challenges. 

The  questionnaire  asks  your  views  about  the  quality  and  value  of  the  written  thesis 
product.  (In  a  separate  questionnaire,  we're  also  asking  students  to  share  their 
views  of  value  of  the  thesis  experience  and  the  extent  to  which  they  feel  that  we- 
their  faculty  advisors— have  been  helpful  in  assisting  them  in  completing  their 
theses). 

As  you'll  see,  the  questionnaire  is  very  brief  and  easy  to  complete,  so  it  shouldn't 
take  much  of  your  time. 

One  final  point  concerning  how  the  information  will  be  used.  Gail  Thomas  will 
provide  quarterly  feedback  to  the  faculty,  in  aggregate  form,  based  on  all  advisors' 
responses.  We  do  not  intend  to  provide  any  individual  faculty  feedback,  so  if 
you're  interested  in  your  own  assessments,  please  make  copies  of  your  completed 
questionnaires  before  turning  them  in. 

We  appreciate  your  effort  and  support  in  helping  all  of  us  to  improve  the  quality 
of  our  programs  and  enhancing  the  value  of  future  students'  experience  at  NPS. 
Thank  you. 

The  completed  questionnaires  should  be  turned  in  to  Lynn  as  soon  as  possible 
after  you  sign  off  on  your  student's  thesis.  If  you  need  additional  questionnaires 
or  have  any  questions,  see  Gail. 


Figure  B-8:  Thesis  Quality  Assessment  -  Advisor's  Instructions 
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THESIS  QUALITY  ASSESSMENT  Crsd  Date 

Student's  Name  

Your   Name:      ^^__________^_^  Your  Role:  Principal  Advisor Co-advisor Assoc  Advisor 

Student's  (write 

Curriculum        Q         Q         D         D         D        □        D        D        D        D         D        curriculum 

(checkout)        813         814        815         816        817        819.      820        827        837        847        370  Other     number) 

Student's 

Service:       ..<  .  ___  -■        ___  ___  '  ^^-  ' 

(checkone)         Navy        Marine*  Army        AirForce         CoastGuard       Allied  Officer      Civilian 

ThefoUowing  questions  seek>our  attftsmrntconffming  the  quality  of  the  theses  you  that  yew  have  advised    For 
each  statement,  please  check  the  box  that  most  accurately  reflects  your  assessment  of  the  written  thesis  product. 

..."  -  :  '•  ,-•»..'.'.  •'■>  "'■■;■'.'■     ■.,';■      '• 


1.  The  written  document  demonstrates  a  solid  knowledge 
of  relevant  theory  and  conceptual  issues  appropriate  __        __        __        __      .  __ 

to  thesis  topic  LJ         U         LJ        □         Lj 

2.  The  written  document dernonstrates  sound  understanding  .-  ■<'  v  ;; .  - ;  • 
of  relevant  theory  and  conceptual  issues  appropriate  to 

focal  topic  .  U         LJ     .  LJ     JJ        LJ      : 

.3.      The  written  document  demonstrates  competent  ....'■... 

application  of  core  skills  and  techniques  relevant ' 
to  focal  topic 

4.  Thesis  is  well  written;  demonstrates  competent 

writing  and  communication  skills. 

5.  Tlte  written  document  addresses  a  problem,  challenge, 

or  issue  that  is  important  and  relevant  to  current  and/or 
future  OoD  interests. 

6.  The  written  document  satisfies  the  criteria  for  good 
academic  quality  research.         ... 

7.  Thesis  will  enhance  the  positive  image  of  NPS  in  the 
eyes  of  important  DoD  decision  makers. 

8.  Thesis  is  of  publishable  quality.  A  shortened  version 
should  be  (is)  submitted  to  appropriate  journal  or 
magazine  for  publication. 


THANK  YOU 


0 

D 

D 

a 

a 

a 

D 

□ 

a 

D 

D 

□ 

a 

a 

D 

D 

a 

a 

a 

a 

D 

D 

□ 

a 

a 

□ 

D 

D 

a 

□ 

a 

.□ 

m 

D. 

D 

Figure  B-9:  Thesis  Quality  Assessment  -  Advisor's  Questionaire 
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SYSTEMS  MANAGEMENT  DEPARTMENT 

STUDENTS'  THESIS  EXPERIENCE: 

AN  ASSESSMENT 


The  Systems  Management  faculty  is  interested  in  knowing  more  about  your  thesis 
experience  in  order  to  improve  the  value  of  the  experience  to  both  students  and 
DoD.  The  following  brief  questionnaire  will  provide  us  with  feedback  about  your 
experience  with  your  thesis  advisors  and  your  assessments  of  the  value  of  the 
thesis  as  a  learning  experience.  We  ask  about  your  experiences  in  carrying  out 
your  thesis  research,  producing  the  final  writing  product,  and  especially,  the  role 
that  your  advisors  played  in  getting  you  to  mis  point 

One  important  point;  in  the  questionnaire,  we  ask  you  about  your  "advisor(s).H  By 
"advisor,"  we  mean  all  of  the  faculty  "advisors"  who  must  sign  your  final  product: 
your  principal  advisor  or  your  "co-advisors,"  and/or  your  "associate  advisor." 
Please  fill  out  a  questionnaire  on  each  "advisor.""' 

As  you'll  see,  the  questionnaire  is  very  brief  and  easy  to  complete,  so  it  shouldn't 
take  much  of  your  time.  Nonetheless,  despite  the  brevity  of  questionnaire,  the 
information  you  provide  is  important  and  will  definitely  be  informative  to  the 
faculty. 

One  final  point  concerning  how  the  information  will  be  used.  The  total  faculty 
will  receive  feedback,  in  aggregate  form,  based  on  all  of  the  students'  responses. 
However,  we  also  want  to  be  able  to  give  individual  faculty  the  feedback  from 
those  students  that  they  advised.  So  we  will  provide  anonymous  feedback  to  the 
advisors  only  after  you  have  graduated.  Be  assured  that  we  have  no  desire  to 
identify  specific  student  names  with  any  questionnaire,  although  we  would  encour- 
age you  to  share  your  views  with  your  advisoifs).  The  Associate  Chairman  for 
instruction  will  provide  feedback  to  the  faculty,  collectively  and  individually. 

We  appreciate  your  effort  and  support  in  helping  lis  improve  future  students' 
experience  at  NPS.   Thank  you. 

The  completed  questionnaires  should  be  turned  in  to  the  Department  Chairman's 
secretary  in  1-230  when  you  bring  your  completed  thesis  for  the  Chairman's 
signature. 


Figure  B-10:  Thesis  Quality  Assessment  -  Student's  Instructions 
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THESIS  ADVISING  AND  THESIS  QUALITY  ASSESSMENT  Cnd  Date 

Advisor's   Name:      Principal  Advisor  Co-advisor Assoc  Advisor 

^auum   nnDDnaDDDDn    cSLn 

(checkone)         813         814        815        816        817        819        820        827        837        847  370       Other    tamiber) 

Your  Service     

(checkone)        Navy        Marines         Army       Air  Force        Coast  Guard      Allied  Officer     Civilian 

The  following  eleven  questions  ask  your  views  about  ytrar  thesis  ad  visorts)  and  how  they  attributed  to  your  learning  and 
assisted  you  in  completing  your  thesis.   For  each  statement,  please  check  the  box  that  most  accurately  reflects  your 
response.  Please  complete  a  separate  questionnaire  for  each  of  tout  thesis  advisors/readers. 


X.     My  advisor  was  available  to  provide  help  and        .,  

guidance  in  completing  my  thesis  project  1 I  I I  I I         I I         I I 

2.  VTy  mAinnnr  pigvided  aignifiiMnt  miihnu  in  

conceptualising  the  problem  that  my  thesis  addressed.  LJ  U  l_l         U         U 

3.  My  advisor  was  helpful  in  grading  me  through  the  

data  collection  and  analysis  stages  of  my  work.  | I  I I  I I      "  I I         I | 

4.  My  advisor  was  helpful  in  guiding  me  through  the  ,  

writing  and  editing  phases  of  my  thesis.  I I  I I  I I         I I        I I 

5.  My  advisor  was  helpful  in  getting  me  to  see  the 
relevance  and  importance  of  my  results  to  DoN/DoD. 

6.  I  feel  that  my  thesis  is  a  quality  product  and  represents 
some  of  my  very  best  work  to  date. 

7.  The  thesis  was  an  opportunity  for  me  to  apply  the 
knowledge  and  skills  I  acquired  at  NFS. 

8.  Without  hesitation,  I  would  recommend  my  advisor  to  .             

my  fellow  students  who  want  trt  do  a  superior  thesis.  I I  I I  I I  I I  LJ 

9.  As  a  result  of  doing  my  thesis,  I  now  feel  confident  about  

my  ability  to  do  quality  research  and/or  analyses.  Li  I I  I I         I I         I I 

10.  I  am  truly  proud  of  my  thesis  research  product  l_J         I I  I I         I I         I I 

IX  Overall,  the  thesis  project  was  a  valuable  learning  . 

experience.  U         I II I         LJ         LJ 

THANK  YOU  AND  BEST  OF  LUCK  IN  YOUR  FUTURE  ASSIGNMENTS. 
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Figure  B-ll:  Thesis  Quality  Assessment  -  Student's  Questionaire 
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Figure  B-12:  Validation  Worksheet 
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SOF  INSTRUCTIONS  FOR  INSTRUCTORS  AND  SECTION  LEADERS 

Please  read  Statement  of  Purpose  to  Stndents 

STATEMENT  OF  PURPOSE;  Student  Opinion  Forms  (SOFs)  serve  two  purposes.  The  numerical 
answers  to  the  questions  on  the  front  of  the  form  are  used  by  the  Department  Chairman  and  the 
Administration  in  evaluating  the  instructor  for  pay,  promotion,  tenure  and  awards.  The  instructor  uses 
these  answers  along  with  the  written  comments  on  the  back  of  the  form  for  improving  the  course 
materials  and  instruction  methods.  The  written  comments  are  seen  only  by  the  instructor.  Objective: 
individual  responses  on  the  SOFs  permit  useful  evaluation  of  both  the  instruction  and  the  course. 

INSTRUCTIONS  TO  THE  INSTRUCTOR: 

(a)  Completely  fill  out  the  course  and  instructor  data  sheet  provided  with  the  SOFs. 

(b)  During  class  in  the  1 1th  week  of  the  quarter,  read  aloud  the  above  Statement  of  Purpose  and 
provide  class  time  for  the  completion  of  the  forms  by  the  students.  Do  not  elicit  any  specific  responses 
from  the  students. 

(c)  Identify  the  Section  Leader  or  Senior  Officer  student  to  be  in  charge  of  collecting  the  forms  and 
returning  them  sealed  in  the  envelope  provided  to  the  Department  Secretary  or  Admin  Support 
Assistant  (ASA).  Indicate  his/her  name  in  section  4  of  Cover  Sheet 

(d)  Hand  out  the  forms  and  ask  each  student  to  enter  the  SOF  Report  Number  assigned  to  mis  course 
as  indicated  on  the  instructor  cover  sheet 

INSTRUCTIONS  TO  SECTION  TRADER  OR  SENIOR  OFFICER: 

(a)  Forms  are  to  be  tilled  out  individually;  no  student  should  suggest  particular  responses  to  other 
students. 

(b)  Upon  completion  of  the  forms  by  students,  collect  the  forms  and  enter  a  three  digit  sequence 
number  (right-justified,  beginning  with  001 )  into  the  Sub-SOF  number  part  of  each  form.  This  should  be 
done  in  such  a  way  as  to  preserve  the  anonymity  of  the  individual  student 

(c)  Place  all  completed  forms,  in  numerical  order,  together  with  the  Cover  Sheet  in  the  envelope 
provided  by  the  instructor.  Be  sure  to  seal  the  envelope  to  maintain  the  confidentiality  of  these 
forms. 

**(d)    The  Section  Leader  or  Senior  Officer  is  directed  to  return  the  sealed  envelope  with  the 
completed  SOFs  to  the  Department's  Secretary  or  ASA  as  soon  as  SOFs  are  completed  but  never  later 
than  the  Wednesday  of  finals  week.  On  the  outside  of  the  sealed  envelope  indicate  the  date  SOFs  were 
administered. 

**NOTE;  A  written  report  addressed  to  the  Associate  Provost  for  Instruction  must  be  prepared  if  SOFs 
are  not  administered  or  submission  cannot  be  accomplished  by  Wednesday  of  finals  week. 

*•  New  Items  REV  6/96 


Figure  B-13:  SOF  Instructions 
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COURSE  NO. 

INSTRUCTOR  NAME . 


SEGMENT- 


STUDENT  OPINION  FORM 

NPSS040/2  (BEV  3-64) 


Proper  Mark      bnpropw  Mtrhs 
PLEASE  USE  SOFT  BLACK  PENCIl.  ONLY -DO  NOT  USE  INK.  EXAMPLES:  QfQQ       g>®QQ 


REPORT  NO. 

SUB-S.O.FNo. 

S.CXF.NO. 

0    © 

© 

© 

©       © 

©   © 

© 

© 

©       © 

©   © 

© 

© 

©       © 

©    © 

© 

© 

©       © 

©   © 
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©       © 

©    ® 
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© 

©       © 

©    © 

© 

© 

©       © 

©    © 

© 

© 

©       © 

©   © 

© 

© 

©       © 

©    © 

© 

© 

©       © 

CUR-SPECIALTY 

■flJMBER 

© 

® 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

MRS  THIS 

QTR 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

_£_ 

© 

QTRS 

COMPTO 

® 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

© 

_©_ 

© 

FOR  ME  THIS 

COURSE  IS: 

REQUIRED 

© 

ELECTIVE 

© 

Qui        tu 


Eg  o  go  .5 

So  s  Si  28 

1.  The  course  was  wall  organized (?)  ®  ©  ©  ®  ® 

2.  Time  in  class  was  spent  effectively ®  ©  ®  ©  ©  © 

3.  The  instructor  seemed  to  know  whan  students  didn't  understand  the  material ®  ©  ©  ©  ©  ® 

4.  Difficult  concepts  were  made  understandable  , ©  ©  ©  ©  ©  © 

5.  i  had  confidence  in  the  instructor's  knowledge  of  the  subject ©  ©  ®  ©  ©  © 

6.  I  felt  free  to  ask  questions ©  ®  ©  ©  ©  ® 

7.  The  instructor  was  prepared  for  class  ••^^- ®  ©  ©  ®  ©  ® 

8.  The  instructor's  objectives  tor  the  course  have  been  made  clear*^' B^^» ®  ©  ®  ©  ®  ® 

9.  The  instructor  made  mis  course  a  worthwhile  learnii]^axB»rVc<| .../ .^^TT ®  ®  ©  ©  ©  © 

10.  The  instructor  stimulated  my  interest  In  !he"J^jec/Aa  I ....  .^T ©  ©  ®  ®  ©  © 

1 1 .  The  instructor  cared  about  jlgjfent  f ^ress|in^3i«*^iis  share  in  helping  us  to  learn ©  ©  ©  ©  ©  © 


PLEASE  USE  THE  FOLLOWiNJ^CALE 


5.  Outstanding      (Among  the  top 

4.  Excellent  (Among  the  lop  JO%) 

3.  About  Average  (Middle 


EXT  FIVE  ITEMS: 

(In  the  low**  30**) 
<m  the  lowest  10%) 
0.  Not  AppRcable.'Don't  know/There  were  none 


O  E  A  F  P  HA 

12.  Overall.  I  would  rate  this  instructor  ©  ©  ©  ®  ©  © 

13.  Overall.  I  would  rate  this  course ©  ©  ©  ©  ©  ® 

14.  Overall.  I  would  rale  the  texlbook(s)  ©  ®  ®  ©  ©  ® 

15.  Overall,  i  would  rate  the  quality  ol  the  exams  ©  ®  ®  ®  ©  ® 

16.  Overall.  I  would  rate  the  laboratories  ®  ©  @  ®  ©  @ 


FOR  THE  STUDENT:  THIS  IS  IMPORTANT  DATA. 

AFTER  ALL  GRADES  HAVE  BEEN  TURNED  IN  TO  THE  REGISTRAR,  THE  COMMENTS 
AND  A  STATISTICAL  SUMMARY  OF  THE  INFORMATION  FROM  THESE  FORMS  WILL  BE 
RETURNED  TO  THE  INSTRUCTOR  FOR  COURSE  EVALUATION  AND  TEACHING 
IMPROVEMENT  PURPOSES.  THE  STATISTICAL  SUMMARY  WILL  ALSO  BE  USED  BY  THE 
ADMINISTRATION  FOR  EVALUATION  OFTEACHING  EFFECTIVENESS. 

DATA  OBTAINED  UNDER  AUTHORITY  OF  5  USC  301. 


17.®  ©  ©  ©  ©  © 

18.®  ®  ®  ©  ©  @ 

19.®  ©  ©  ®  ©  ® 

20©  ©  ©  ©  ©  © 


*  *  PLEASE  USE  SPACE  ON  REVERSE  SIDE  FOR  COMMENTS. 


94«SJ>aSX2-Pn-3*321 


Figure  B-14:  SOF  Form  (Front) 
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Figure  B-15:  SOF  Form  (Back) 
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Course  No. 

Title: 

Quarter: 


DEPARTMENT  OF  SYSTEMS  MANAGEMENT 

Course  Journal 
Instructor 


Academic  Year  19 


Complete  Course  Journal  already  on  file  {See 


Qtr 


Textbook (s) : 


Frequency  Distribution  of  Grades 


AY 


Grade 

A 

A- 

B+ 

B 

B- 

C* 

C 

C- 

D* 

D 

X 

I 

p 

F 

Point* 

4.0 

3.7 

3.3 

3.0 

2.7 

2.3 

2.0 

1.7 

1.3 

1.0 

0.0 

Frequency 

Composite  QPR  for  class  based  on  letter  grades  awarded 


Attachments  (check  all  that  apply) 

Course  outline/assignment  schedule  or  description  of  course 

as  actually  taught  this  quarter 

Reading  list 

Homework  assignments,  projects,  term  papers,  etc. 

Examinations  and  quizzes 

Other  materials  {notes,  handouts,  case  studies,  etc.) 

Comments  about  course,  tests,  students,  etc.;  recommendations 


Signature  of  Instructor 


Co- instructor 


Figure  B-16:  Course  Journal 
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USER  Manual 


July  1997 


SMIDSS 


Systems  Management  Intranet  Decision  Support  System 
(An  Intranet  based  decision  support  tool  Faculty,  Staff,  Administrators  and 
Students  of  the  Department  of  Systems  Management 
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User  Manual 

This  manual  will  cover  the  specific  requirements  for  accessing  the  Systems  Management 
Intranet  Decision  Support  system.  (SMIDSS).  This  manual  is  not  intended  to  provide 
instruction  on  an  individual  WWW  browser. 

In  order  to  use  SMIDSS  users  are  expected  to  know  how  to  do  the  following 

•  Start  their  computer 

•  Log  onto  the  Department  of  Systems  Management  local  area  network  (LAN) 

•  Start  the  WWW  browser 

Required  Software: 

The  only  required  software  for  a  client  machine  is  an  HTML  3  compliant  WWW 
browser.  Free  versions  of  a  compatible  browser  are  available  from  Microsoft  at 
http://www.microsoft.com/.  Or  contact  the  computer  support  personnel  in  the  department. 

Security: 

In  order  to  access  any  of  the  SMIDSS  processes  you  must  have  a  valid  user  name  and 
password.  Contact  the  SMIDSS  system  administrator  for  an  account. 
Upon  creating  your  account  you  will  be  placed  in  a  user  group.   You  will  be  a  student, 
faculty,  staff  or  the  department  chairman.    Each  of  these  types  of  users  has  access  to 
different  areas  of  SMIDSS. 
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All  Users: 

In  order  to  access  the  SMIDSS  homepage,  direct  your  browser  to  the  following 
URL:  http://131.120.4l .90/SMIDSS/homepage.htm .  The  following  page  will  be  displayed  as 
shown  in  Figure  1 . 


Welcome  to  SMIDSS 


This  page  is  for  the  intended  use  of  the  Department  Prototype  Administrator,  Education  Technician,  Faculty 

and  Students  of  the  Department  of  Systems  Management,  Naval  Postgraduate  School,  Monterey,  CA. 

Access  to  links  from  this  pages  requires  a  User  ID  and  Password. 


'    System  Description 
•    User  Processes 


System  Description 

Welcome  to  the  Systems  Management  Intranet  Decision  Support  System. 

The  System  consists  oE 

1  Pentium  166MHZ  server  (OS  is  Windows  NT  4.0  Workstation) 

Server  Software:  P'Refflv's  Website  Professional 

ODBC  Database  Connectivity:  Allaire  Corp's  Cold  Fusion  Professional  (Version  2.0) 

Database:  MS  Access  Version  7  0  format 


Processes 


Type  User 


Description 


^Prototype  Administrator  Menu  options  for  the  Administrator 

i  Education  Technician    iMenu  options  for  the  Department  Ed  Tech 


Faculty 


Menu  options  of  teaching  and  advising  faculty 


Student 


Menu  options  for  enrolled  students 


Staff 


Menu  options  for  Department  Staff 


Vwv>  the  Users  Manual 


Naval  Postgraduate  School 

Department  of  Systems  Management 

Monterey,  CA  93943 


Figure  C-l:  SMIDSS  Homepage 

From  this  page  you  will  be  able  to  access  the  processes  based  upon  the  "Type  User"  you 


are. 
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Students: 

Students  have  access  to  the  SOF  completion  form  only  during  a  specified  period  at  the 
end  of  each  academic  quarter.  The  username  and  password  for  this  area  will  change 
frequently.  Their  respective  section  leader  will  give  students  the  username  and  password. 
Students  can  also  access  the  general  information  data  retrieval  functions  of  SMIDSS. 
Information  in  this  area  includes  faculty  information  (Such  as  phone  number,  e-mail 
address,  office,  etc.)  and  course  information. 

Students  will  not  be  able  to  add  information  or  make  changes  to  information  in  the 
database. 


®ffinffjf» 


!»>»Bea!QiSb>ra>3&e«eaez9b<a«c>i!£^^ 


«Bisb«MSwe!CBeaiieeswe<<Sb«eiESb<>!icsa>aae>e9e^^ 


Figure  C-2:  Student  Homepage 
Faculty: 

Faculty  have  access  to  the  general  information  retrieval  area.  Faculty  are  not  allowed  to 

make  changes  directly  to  the  database.  Any  modifications  to  the  database  should  be  sent 

to  education  technician.    When  changes  to  the  database  are  made,  SMIDSS  will  send 

verification  e-mail  to  you  when  the  changes  are  posted. 
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Figure  C-3:  Faculty  Homepage 
Faculty  members  also  have  access  to  course  information  and  resources.  These  resources 

are  used  to  capture  information  pertaining  to  courses  and  scheduling.  All  information  is 

stored  in  a  secured  database.  The  information  is  only  available  to  faculty,  and  department 

administration  personnel. 


Figure  C-4:  Faculty  Course  Information  and  Resources 
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Staff: 

Department  members  have  access  to  the  general  information  retrieval  area  of  SMIDSS. 
Staff  members  are  not  allowed  to  make  changes  directly  to  the  database. 


— 


Department  Staff 

Menu  Options 


•  Course  Description  Information 

•  General  Instructor  Information 


iuHOMEl 


Figure  C-5:  Staff  Homepage 


Education  Technician  pages: 


Figure  C-6:  Education  Technician  Homepage 


119 


Textbook  Process: 

As  the  Education  Technician,  you  can  order  individual  textbooks,  adding  them  to  your 
database  or  you  can  view  and  print  the  department  textbook  requisition  database.  This  is 
done  by  accessing  the  General  and  Administrative  page. 


Figure  C-7:  Education  Technician  General  and  Administrative 

SOF  Maintenance: 

The  SOF  Maintenance  Area  may  be  accessed  through  the  General  and  Administrative 

page  from  the  Education  Technician  Homepage. 

At  a  specified  point  in  each  quarter  you  should  create  blank  files  to  store  student  SOF 

Comments. 

WARNING:     THIS  PROCESS  OVERWRITES  ALL  PREVIOUS  VERSIONS  OF  SOF 

COMMENT  FILES  AND  CANNOT  BE  REVERSED. 

To  create  the  files  go  to  the  Student  Observation  Form  Maintenance  Area.  You  have  the 

option  of  creating  files  for  all  instructors  for  individual  instructors. 
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The  SOF  Maintenance  area  is  also  where  you  go  to  create  the  Department  Chairman's 

SOF  report  and  send  SOF  Comment  e-mails  to  instructors. 

SOF  Comment  e-mails  should  only  be  sent  when  you  are  instructed  to  do  so.    Each 

instructor  will  receive  only  one  e-mail  containing  comments  for  all  course  he/she  taught 

in  the  last  SOF  period. 

Course  Maintenance: 


Figure  C-8:  Education  Technician  Course  Maintenance 

Course  Maintenance  may  be  accessed  through  the  Course  Maintenance  page  from  the 
Education  Technician  Homepage. 

The  following  processes  are  available:  Add  a  Course  to  the  Database,  Update  Course 
Information,  and  Delete  a  Course  from  the  Database. 
WARNING:  UPDATING  AND  DELETING  INFORMATION  IS  NOT  REVERSIBLE! 
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Faculty  Maintenance: 

Faculty  Maintenance  may  be  accessed  through  the  Faculty  Maintenance  Page  from  the 
Education  Technician  Homepage. 


Figure  C-9:  Education  Technician  Faculty  Maintenance 

The  following  processes  are  available:  Faculty  Registration  (Add  a  faculty  member  to  the 
database),  Assign  a  Faculty  Member  to  Teach,  Update  Faculty  Information,  and  Delete  a 
Faculty  Member. 
WARNING:  UPDATING  AND  DELETING  INFORMATION  IS  NOT  REVERSD3LE! 

SMTDSS  Administrator  Page: 

The  administrator  link  takes  you  to  the  Prototype  test  page.  This  page  has  a  link  to  each 
prototype  process  and  is  intended  as  a  efficient  means  to  update  pages  and  test  links. 
From  the  Website  Properties  set  up  the  SMIDSS  Administrator  will  have  access  to 
previously  addressed  pages  for  all  classes  of  users  (See  the  SMIDSS  Administrator's 
Manual  for  more  information). 
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Security: 

Access  to  any  of  the  SMIDSS  Process  pages  requires  a  username  and  password. 
Usernames  and  passwords  can  be  obtained  from  the  SMIDSS  system  administrator.  A 
link  to  the  SMIDSS  Administrator  is  located  on  the  SMIDSS  Homepage. 

Authentication: 

Upon  trying  to  access  a  process  page  a  window  like  Figure  10  will  pop  up 


i  Authentication 


. 


You  need  a  password  to  access  this  page. 

Resource-  Web  Server 

Username: 


Password: 


Figure  C-10:  Authentication  Window 

To  continue  enter  your  SMIDSS  username  and  password  and  select  OK. 


Entering  information: 

Entering  information  involves  typing  into  a  textbox,  or  making  selections  from  dropdown 
lists,  checkboxes  or  radio  buttons  as  shown  in  Figure  1 1 . 


12: 


textbox 


"3 


Drop  down  box 


Checkbox 


|Select  Course  ^j     r  M  !~  T  T  W  l~  ThP'F 
C  lHr<~  2Hisf=-AHrs 


Figure  C-ll:  Input  Options 

A  selection  from  drop  down  boxes  involves  clicking  on  the  down  arrow.  -* 
Selections  for  check  boxes  (squares)  and  radio  buttons  (circles)  involve  clicking  inside 
the  shape.    Checkboxes  allow  you  to  make  multiple  selections.    A  radio  button  allows 
you  to  make  only  one  selection  from  the  options  displayed. 


Pressing  the  submit  button 


Submit 


submits  your  information  to  the  database  and 


causes  a  verification  page  to  appear.  In  some  instances  SMIDSS  will  also  send  an  e-mail 
veirifaction  message  t  the  users.  You  may  back  out  of  any  page  by  simply  using  the 
browsers  back  button. 
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APPENDIX  D  -  ADMINISTRATOR  MANUAL 
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System  Administrator  Manual 


July  1997 


SMIDSS 


Systems  Management  Intranet  Decision  Support  System 
(An  Intranet  based  decision  support  tool  Faculty,  Staff,  Administrators  and 
Students  of  the  Department  of  Systems  Management 
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Administrators  Manual 

This  manual  will  cover  the  specific  requirements  for  installation  and  setup  of  the  software 
components  of  the  Systems  Management  Intranet  Decision  Support  system.  (SMIDSS). 

The  specific  software  components  are  the  webserver,  ODBC  server,  webpages  and 
database  files. 

Installation: 

The  actual  installation  of  the  webserver  and  ODBC  server  are  automated  and 
sufficiently  covered  in  the  appropriate  user  manuals  accompanying  the  software. 

After  installing  the  Webserver  a  directory  structure  as  depicted  in  figure  1  should  be 
created. 

P~l  Smidss 

:-C~\  DatabaseFiles 

j  -C3  SOFComments 

H-fl  wwwroot 

FR--P"!  images 

E  Q  Security 

i-C~]  CourseJournal 
--•Pi  CourseMaint 
j--Pl  Courses 
| --Q  DeptChair 
I--P1  edtech 
j-~£l  Faculty 
j-Pl  FacultyMaint 
!■■■■{    >  IntraDepartment 
I    Q]  preferences 
;■  I    i  SOFForms 
E"Q  Textbooks 

Qj  Requisitions 
•■-Pi  ThesisAssessrnent 

Figure  D-l:  SMIDSS  Directory  Structure 
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The  SMIDSS  directory  is  used  to  provide  a  single  directory  off  the  directory  tree  of  the 
host  machine  to  store  all  the  SMIDSS  Files.  Note:  The  Webserver,  if  installed  according 
to  the  defaults,  will  reside  in  a  different  directory. 

The  DatabaseFiles  directory,  as  the  name  implies,  is  used  to  store  the  database  that 
supports  the  decision  support  function  of  SMIDSS.  The  location  is  such  that  the  files  are 
higher  in  the  directory  than  the  root  directory  of  the  webserver  (wwwroot).  The  directory 
is  placed  higher  in  the  structure  so  that  the  webserver  security  will  prevent  any  Intranet 
network  user  to  access  the  datafiles  directly.  This  is  done  by  the  webserver  by  restricting 
access  of  users  to  directories  below  the  specified  root.  (Specifying  the  webserver  root 
will  be  covered  later). 

There  is  actually  only  one  datafile  used  by  SMIDSS.  The  file  nine  tables. 
The  actual  structure  of  the  tables  is  included  at  appendix  5. 

Similarly  SOFComments  is  placed  hierarchically  higher  in  the  structure.  The  purpose  of 
the  SOFComments  directory  is  to  securely  store  the  comments  made  by  students  on  the 
SOF  input  form. 

The  wwwroot  directory  holds  all  the  HTML  (and  DBML)  pages  that  the  server  displays 
to  users.  Additionally  by  default,  your  main  welcome  page,  or  homepage  is  stored  in  the 
wwwroot  directory. 
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All  of  the  subdirectories  of  wwwroot  contain  pages  linked  to  a  specific  process  or 
function.  Establishing  subdirectories  for  each  process  will  facilitate  maintenance  and 
modification  of  page  design. 

Mnemonics  are  used  for  the  directory  naming  so  that  the  process  they  are  related  to  is 
clear.  The  entire  SMIDSS  directory  should  be  protected  from  casual  browsing  by  not 
sharing  or  allowing  access  from  the  LAN.  You  don't  want  to  allow  unauthorized  users  to 
place  HTML  pages  into  to  the  SMIDSS  system  that  may  allow  them  to  access  restricted 
information.  The  databasefiles  and  the  SOFComments  directories  should  be  protected  so 
that  only  the  SMIDSS  system  administrator  can  access  these  directories.  This  is 
necessary  to  ensure  the  integrity  and  confidentiality  of  the  information. 

The  security  directory  is  used  to  further  subordinate  the  HTML  files  from  the  level  of  the 
wwwroot.  The  name  of  the  directory  serves  as  a  visual  reminder  that  the  pages  provide 
access  to  different  classes  of  users  based  on  the  permissions  granted  to  the  users. 

The  deptchair  and  edtech  contain  pages  intended  for  a  specific  class  of  user.  User  classes 
will  be  discussed  later.  In  the  website  properties,  access  should  be  restricted  to  only  the 
department  chairman  and  education  technician  for  the  dept  chair  directory  and  the 
education  technician  only  for  the  edtech  directory. 

The  faculty  directory  contains  files  that  collect  and  display  information  pertaining  to 
faculty  members. 
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The  facultymaint  directory  holds  the  pages  necessary  to  make  additions,  deletions  or 
changes  to  faculty  database  information. 

The  Intradepartment  directory  contains  the  files  used  for  communication  of  messages 
between  the  Ed.  Tech  .  and  faculty.  Although  not  implemented  in  the  prototype,  it  is 
recommended  that  a  subdirectory  be  created  in  Intradepartment  to  handle  routine 
department  communications,  such  as  newsletters  or  other  messages  for  the  staff  as  a 
group. 

The  preferences  directory  holds  the  files  for  capturing  and  displaying  faculty  teaching 
preferences. 

The  textbooks  directory  has  the  files  necessary  to  display  textbook  listings  for  each 
course.  The  subdirectory  Requisitions  is  separate  to  enable  separate  security  to  be  placed 
on  the  actual  requisition  forms.  For  example,  students  and  faculty  can  access  the 
information  about  what  texts  are  required  for  a  class,  but  only  faculty  can  requisition  a 
text. 

The  ThesisAssessment  directory  holds  the  pages  that  collect  information  pertaining  to 
thesis  assessments. 

SECURITY 
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The  SMIDSS  system  administrator  is  the  only  person  that  should  be  allowed  to  place  files 
in  any  of  the  SMIDSS  directories.  Also,  the  webserver  properties  should  be  secured  to 
that  the  administrator  is  the  only  user  that  can  access  the  webserver  controls. 

In  order  to  facilitate  access  while  maintaining  security  the  following  user  classes  should 
be  established  in  the  webserver  properties. 

•  System  administrator 

•  Dept  Admin 

•  Student 

•  Faculty 

•  Staff 

WEBSITE 

Webserver  properties  can  be  set  from  either  the  Start  ffi Start)  Menu,  or  by  right  clicking 
the  website  icon  in  the  tray  on  the  active  title  bar. 
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WebSite  Server  Properties 


jftlefaftytl   gapping"'  ]  ^DifllBSr^'fl ^.Osers^l   'G roups    | 


Workiig  Din 

IbNfflBME 

CGI  Temp  Dir: 

|  C:  \WebS  ite\cgi-temp 

£drnin  Addr: 

Run  mode: 

|  System  service  (tray)           "^ 

Also  called  the 
server  root 

CGI  ternpfiles  are 
created  here 

Used  in  generated 
maltaURLs 


p  Network- 


Normal  Port    80 


Timeouts  (s):  Pecy; 


100     Send: 


100 


SSL  Port:    443 


Max  Simultaneous  Connects: 


256 


Hold  connections  open  for  re-use  C 


V^rtoillB 


OK 


Cancel 


^ppfc 


Help 


Figure  D-2:  Website  Server  Properties 

The  Working  Dir:  is  the  location  of  the  website  files.  This  should  not  be  changed. 

CGI  Temp  Dir  is  used  by  website  for  the  execution  of  CGI  scripts.  This  should  not  be 

changed. 

Admin  Addr:  is  not  required.  This  is  used  if  the  administrator  wants  to  automatically  add 

a  webmaster  address  to  pages. 

Run  mode  selects  how  the  server  runs.   The  options  are  System  service  (Tray),  System 

Service  (hidden),  Application  (minimized)  and  Application  (Tray).  Only  the  last  two  are 

options  when  used  in  Windows  95  since  Windows  95  does  not  support  services.    It  is 

recommended  that  the  server  run  as  a  System  service  (Tray)  when  running  in  Windows 

NT. 
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The  network  section  allows  you  to  change  any  network  connection  parameters.    The 
defaults  are  shown  and  should  be  used  unless  the  network  configuration  requires  a 


change. 


WebSite  Servef  Properties 


Access.CpnbpL„J .  _  FubSshing  Control 

General         Identity    1    Mapping   ]    DirLi 


3  i£ 


CGI 


ru..J  cue 
domah  - 


Leave  blank  tc  log  :: 
main  access  Jog  fie. 


e 


N  OTE:  You  must  define  document  and  CGI  mappings  for  a! 
prefixed  URL  paths.  Use  the  lden%  Wizard  or.  a^ter  making 
changes  here,  switch  to  the  Mapping  page  and  verity  that  this  is 
the  case. 


OK 


Cancel 


-e;r 


Figure  D-3:  Website  Identity 


The  identity  tab  is  used  to  specify  or  change  the  URL  or  IP  address  of  the  server.  This 
tab  does  not  change  the  IP  address  contained  in  the  network  properties  tab  of  the  OS. 
The  server  name  is  initially  entered  when  website  is  installed.    This  tab  is  also  where 


multiple  identities  are  established  as  described  in  the  website  users  manual. 


WebSite  Server  Properties 


^eheraLj;     Identity     /gapping  '■  |  '^DrSig  /|Vj-isers"  "j^G'w"  I 
D  ocument  U  R  L  Path  D  irectory  (full  or  document-relative] 


/cfstand/ 

/java/ 

/javasdk/ 

/perl5/ 

/pubjjsh/ 

-  List  S  elector  — — — - 
(• jDpct^eritsj 
Q  Redirect  - 
0  Windows  CGI 
■■■O  Standard  CGI 
0DOSCGL 
O  Cortfent  Types 
C  Directory  Icons 


C:\WebSite\htdocs\ 

C:  \WebS  ite\cfusion\cf  stand\ 

C:\WebSite\java\ 

C:  \WebS  ite\ja  va\doc\ 

C:\WebSite\perl5\ 

C:\WebSite\publish\ 


Document  URL  Path 


Directory  (full  or  document-relativel 


Delete.    -J    -Replace 


■Add 


OK 


Cancel 


&ppJy 


Help 


Figure  D-4:  Website  Properties  -  Mapping 

The  mapping  tab  is  where  you  establish  the  root  directory  of  the  server.  Website  security 
will  not  allow  access  to  directories  higher  that  than  the  root  (denoted  by  I).  The  only 
directory  you  should  change  is  the  root. 
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WebSite  Server  Properties 


..J  .^Logging.      -CGI  . 

General    \  ' [aertty    \     Mapb,ng         l>L.    v     :    ,-, 


-  Features - 


^  IE  nafcJe  dir ecto  ry  fojngsj" 
I?  Extended  format 
■Wj  Icons are links 
W..  Description  from  HTML 
I?  Show  content  types 
I?  Use  HTML3  tables 


-Special  Documents;           — —— 

Default  | welcome." 

Header  jttheader 

Footer:    ttfooter 

FiteDesc:  jWildescctl 

Ignore  Patterns 


ti* 


.bak 
.ctr 


m 


Delete 


Add. 


-Special  Icon; 
Unkn,  Type 
Parent  Drn 
Sub  Die 
Spacer 

s- — ■-■-v-.-.  ---■ — — 

lunknowagif 

jbackgif 

Imenugif 

jdblank.gif             ;.; 

OK 


Cancel 


aw 


Help 


Figure  D-5:  Website  Properties  -  Dir  Listing 

The  Dir  Listing  tab  contains  controls  for  specifying  the  default  html  page,  some  of  the 
html  default  tags,  and  some  security  features  of  website.  To  specify  what  page  is 
displayed  by  default,  specify  a  page  name  in  the  Special  Documents  section  under  the 
Default  Field.  In  this  example  if  no  page  is  specified  in  a  URL,  the  webserver  will 
display  a  page  that  begins  with  welcome.*  (wildcards  are  in  effect).  As  shown  in  the 
features  section,  "Enable  directory  listings"  is  enabled.  If  a  file  named  welcome  is  not 
found  than  the  webserver  will  display  a  complete  directory  listing.  It  is  recommended 
that  "Enable  directory  listings"  be  disabled  to  enhance  security. 
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j  Authentication  R  ealm  - 


Iweb  Server 


j^j     '•""  N 


ew... 


Delete 


User  - 

-..•..-— ■••t- 

"     New... 

'Deiete:::| 

1                          F 

Rasswerd.:-; '■■ 

p  Group  Membership- 
;  Available  Groups: 


Member  Of: 


•Atfd».' 


:<  Remove 


OK 


Cancel 


Apply 


Help 


Figure  D-6:  Website  Properties  -  Users 

The  users  tab  is  used  to  set  users  and  passwords.  The  users  created  here  are  not  added  to 
the  list  of  workstation  or  domain  users  in  the  OS.  Users  are  also  assigned  group 
membership  from  this  tab. 
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WebSite  Server  Properties 


-Group     - 

New..! 

'  Delete.    \ 

1 .._ 

:,,_  M . 

I- 


Group  Membership- 
Non-Members: 


Members; 


Add» 


«  Remove 


OK 


Cancel 


Apply 


Help 


Figure  D-7:  Website  Properties  -  Groups 

The  groups  tabs  is  where  you  create  groups  or  classes  of  users  as  recommended  above. 
You  can  also  assign  existing  users  to  groups  from  this  tab. 
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WebSite  Server  Properties 


ppejlikr  ;l dentity  •  | ,  iMapp^g^j^^S 


13  roups 


-  Access Control a  ,:-j ^PQblishing "Con^P  |  iibgggg  I  ISI 
URL  Path  or  Special  Function: 

II 


New.... 


|~~  Disable  directory  listings 
I"""  Logical  OR  users  and  class 
'  Require  SSL  connection 


p  Authorized  Users  &  Groups- 
Realm:  Web  Server 


Groups  are  enclosed  bt i  ( ] 
Remove-  I  Add.. 


Qass  Restrictions—— 
O  Deny,  then  Allow 
(?■.  Allow,  then  Deny 

Allow  classes: 


all 


..  then  Deny  classes: 


Delete 


New., 


Cancel 

Apply 

Help^ 

OK 

Figure  D-8:  Website  Properties  -  Access  Control 

The  access  control  tab  is  where  you  specify  what  groups  and  users  have  access  to  what 
directories.  You  can  also  disable  directory  listings  on  a  directory  by  directory  basis  from 
this  tab. 
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WebSite  Server  Properties 


URL  Path 


I 


3 


New... 


Delete 


■Authorized  Users  &  Groups- 
Realm:  Web  Server 
I  [Administrators] 


Groups  are  enclosed  in  [ 
Remove  I  Add. 


V  Require  SSL  connection 


Uploading  of  infine  CGI 
and  API  applications  is 
prohibited 


"DO  NOT  PERMIT  FTP 
ACCESS  TO  YOUR 
WEB  UNLESS  YOU 
DISABLE  INLINE  CGI 
AND  API! 


: 


OK 


Cancel 


Apply 


Help 


Figure  D-9:  Website  Properties  -  Publishing  control 

Publishing  control  is  used  to  control  which  users  can  publish  to  the  site  via  their  web 
browser  (for  example  Netscape  Gold).  It  is  recommended  that  the  values  in  this  tab  not 
be  changed. 
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V/ebSite  Server  Properties 


III  llllll BBBE    . 

GeneraHj  ^Identity    J «  MappjngSJ^^ 
Access^ControI  PuM^hgControl 

-  Log  Re  Paths 


Access:   SffESIfl? 


Server:    server.log 


Error:  jerror.bg 


-Access  Log  Format  -~; — — 

C  Windows'  (WebSite  extended) 
C  Combined  (NCSWCERN);: 
<*   Common  (older  NCSA/CERN) 


-  Client  Hostname  Lookup---— -— — 
I~~  Enable  DNS  Reverse  Lookup 


;usting5l  ..zUjjers^  I r  G  roupsj?] 
Logging  ^|  ~™C£l\  \ 

■  Tracing  Options       --.- 

Q  HTTP  Protocol 

C  Dump  Sent  Data 

j[~  Image  Maps 

j~j  API/CGI  Execution 

£j;  Access  Control 

Cj,  Authentication 

JZ  Control  Threads 

LJ  Service  Threads 
I    CT  Network  I/O •„. 

C  Network  Buffering 
"O  SSLandS-HTTP 


-Clear  All  Tracing 


OK 


] 


Cancel 


4ppiy 


Help 


Figure  D-10:  Website  Properties  -  Logging 

Logging  is  used  to  specify  the  names  of  the  log  files  and  what  attributes  are  logged.  The 
defaults,  shown,  should  be  used  unless  trying  to  track  a  specific  problem. 
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fl 


These  options  are  for  advanced  users  only  We  cannot  provide 
support  for  CGI  operation  if  j^u  customize  these  items.-,     */ 


Windows  CGI  — 
^-Exec  template: 


Standard  CGI  •-• 

Shell  (*  =  associate):  - 


Exec  template: 

|7  NCSA  extra  header  format 


DOS  CGI- 
Shelt 


cmdexe 


-Options:  Normal:         Debug; 


Exec  template: 


UK 


|~p  ~a  <  ~i  >  ~o 

Startup  template: 


|~s  ~x  ~| 
Quiet  Command: 


@ECHOOFFfc&TITLEWeb 


Cancel 

Appfy' 

Help 

OK 

Figure  D-ll:  Website  Properties  -  CGI 

The  CGI  tab  is  used  to  modify  the  CGI  functions  of  Website.   CGI  was  not  used  in  the 
SMIDSS  prototype.  The  default  values  should  be  maintained. 

COLD  FUSION 

The  only  options  available  for  the  administration  of  Cold  Fusion  are  the  specification  of 
data  files.  Cold  fusion  calls  these  the  datasources. 

Datasources  are  set  in  either  the  Cold  Fusion  administrator,  accessed  through  the  Start    ;gQ  start 
menu  or    through  the  ODBC 


icon  in  the  control  panel.  The  interface  is  the 


ODBC 


same. 
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Data  Sources      templates'-'       '-'Mail' 
ODBC  Data  Sources  AvaHable  to  Cold  Fusion 


■CF  Examples 


Desrondb 

venus  DB  Samples 


■r- 


Add,. 


Delete 


OK 


Cancel 


Apply 


Help 


Figure  D-12:  Cold  Fusion  Administration 

To  create  a  datasource  click  the  Add  button. 


Then  on.the  resulting  window  select  the  appropriate  database  type  that  was  used  to  design 
the  tables.  (SMIDSS  was  designed  with  Microsoft  Access). 
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h 

! 

if 
IB 


Create  New  Data  Source 


Vm 

1 


Select  a  driver  for  which  you  want  to  set  up  a  data/source. 


{Microsoft  Access  Driver  Kmdbi 


Version 


Comipa: 


Microsoft  dBase  Driver  f.dbf) 

Microsoft  Excel  Driver  f.xls) 

Microsoft  FoxPro  Driver  f.dbf) 

Microsoft  Text  Driver  (Mxt;  *.csv)    3.50.342800    Microsc 

SQLServer  265.0213        Microsc 


3.50.342800  Microsc 

3.50.342800  Microsc 

3.50.342800  Microsc 

3.50.342800  Microsc 


±1 


Back 


-  Finish 


Cancel 


Figure  D-13:  ODBC  Interface 


Then  select  "finish"  this  displays  a  window  to  allow  you  to  browse  to  the  databasefiles 
directory  and  select  the  sched.mdb  file. 


14: 


JODBC  Microsoft  Access  97  Setup 

■■  .  ■     • 

:• 

'  sKISS^9E2] 

D  ata  S  outce  N  ame:filCouL$e$ 

flK  . 

|  Select  Database 

fxl 

J 

1 

Database  Name 
r  Dat.    ■ = ; 

directories: 
D\WINDOWS\P..ADesktop 

OK 

rifli 

am 

Cancel 

-  Sysl 
<•   1 

^c:\ 
■Pij  windows 
§£  Profiles 
fjrj  edioewen 
f3  Desktop 
ED  My  Briefcase 

J 
J 

Help 

\1  Readonly 
[T  Exclusive 

CI 

J$t  Files  of  Type: 

Drives: 

J  Access  D atabases  (x. mij^j  ■;.-. 

Si  c: 

!•-▼.         ' 

Network... 

Upbons> 

>    1 

„»^._.     ...     -..l'_    _-„^:_.- -~L_JU~_-. 

Figure  D-14:  ODBC  Select  Database 

Selecting  the  network  button  allows  you  to  browse  to  any  shared  directory  on  the  network 

to  link  to  a  file.     Using  this  option  causes  a  network  drive  to  be  mapped  to  your 

workstation. 

LOGS 

As  discussed  Website  logs  all  access.   The  logs  are  stored  in  ASCII  format  and  can  be 

found  in  the  websiteMogs  directory.    The  logs  should  be  reviewed  periodically.    When 

reviewing  the  logs  you  will  notice  some  non-standard  ASCII  characters.    These  strings 

are  caused  by  unknown  server  errors.  The  nonstandard  ASCII  can  be  safely  deleted  from 

the  files. 
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APPENDIX  E  -  DATA  DICTIONARY 
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Table:  CourseDescription 


Columns 

Name 

Type 

ID 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

1 

ColumnWidth: 

Default 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

ID 

Source  Table: 

CourseDescription 

LabHours 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

LabHours 

Source  Table: 

CourseDescription 

LectureHours 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

LectureHours 

Source  Table: 

CourseDescription 

Size 


Table:  CourseDescription 


CourseNumber 

AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 

False 

Variable  Length 
General 
False 

ColumnOrder: 

Default 

ColumnWidth: 

1560 

DisplayControl: 
Ordinal  Position: 

Text  Box 
4 

Required: 
Source  Field: 

False 
CourseNumber 

Source  Table: 

CourseDescription 

TitleCourse 

AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 

False 

Variable  Length 
General 
False 

ColumnOrder: 

Default 

Text 


Text 
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ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

5 

Required: 

False 

Source  Field: 

TitleCourse 

Source  Table: 

CourseDescription 

CurricNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1575 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

CurricNumber 

Source  Table: 

CourseDescription 

Description 

Memo 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

7860 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

Description 

Source  Table: 

CourseDescription 

Quarter 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

Quarter 

Source  Table: 

CourseDescription 

Segments 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder. 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

Segments 

Source  Table: 

CourseDescription 

YearOffered 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

10 

10 


10 
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Required: 

False 

Source  Field: 

YearOffered 

Source  Table: 

CourseDescription 

Enrollment 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

11 

Required: 

False 

Source  Field: 

Enrollment 

Source  Table: 

CourseDescription 

Table  Indexes 

Name 

Number  of  Fields 

JD 

1 

Clustered: 

False 

Distinct  Count: 

9 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

JD 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

ID,  Ascending 

Curric_Number 

1 

Clustered: 

False 

Distinct  Count: 

2 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

Curric_Number 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

CurricNumber,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

9 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

ID,  Ascending 
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Table:  CourseJournal 


Columns 

Name 

Type 

ID 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

ID 

Source  Table: 

CourseJournal 

CourseNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

CourseNumber 

Source  Table: 

CourseJournal 

Quarter 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

Quarter 

Source  Table: 

CourseJournal 

YearOffered 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

YearOffered 

Source  Table: 

CourseJournal 

Description 

Memo 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

5 

Required: 

False 

Source  Field: 

Description 

Size 


10 
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Source  Table: 

CourseJoumal 

Code_FK 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

Code_FK 

Source  Table: 

CourseJoumal 

NumA 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

720 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

NumA 

Source  Table: 

CourseJoumal 

NumAMinus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

NumAMinus 

Source  Table: 

CourseJoumal 

NumBPIus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

10 

Required: 

False 

Source  Field: 

NumBPIus 

Source  Table: 

CourseJoumal 

NumB 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places. 

Auto 

Default  Value: 

0 
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DisplayControl: 

Text  Box 

Ordinal  Position: 

11 

Required: 

False 

Source  Field: 

NumB 

Source  Table: 

CourseJournal 

NumBMinus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

12 

Required: 

False 

Source  Field: 

NumBMinus 

Source  Table: 

CourseJournal 

NumCPIus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

13 

Required: 

False 

Source  Field: 

NumCPIus 

Source  Table: 

CourseJournal 

NumC 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

14 

Required: 

False 

Source  Field: 

NumC 

Source  Table: 

CourseJournal 

NumCMinus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

15 

Required: 

False 

Source  Field: 

NumCMinus 

Source  Table: 

CourseJournal 

NumDPIus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

I51 


Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

16 

Required: 

False 

Source  Field: 

NumDPIus 

Source  Table: 

CourseJournal 

NumD 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

17 

Required: 

False 

Source  Field: 

NumD 

Source  Table: 

CourseJournal 

NumDMinus 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

18 

Required: 

False 

Source  Field: 

NumDMinus 

Source  Table: 

CourseJournal 

NumX 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

19 

Required: 

False 

Source  Field: 

NumX 

Source  Table: 

CourseJournal 

Numlncomplete 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position. 

20 

Required: 

False 

Source  Field: 

Numlncomplete 
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Source  Table: 

CourseJoumal 

NumPass 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder. 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

21 

Required: 

False 

Source  Field: 

NumPass 

Source  Table: 

CourseJoumal 

NumFail 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

22 

Required: 

False 

Source  Field: 

NumFail 

Source  Table: 

CourseJoumal 

CompositeQPR 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

23 

Required: 

False 

Source  Field: 

CompositeQPR 

Source  Table: 

CourseJoumal 

Comments 

Memo 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

24 

Required: 

False 

Source  Field: 

Comments 

Source  Table: 

CourseJoumal 

Outlinefiled 

Yes/No 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

106 

Format: 

Yes/No 

Ordinal  Position: 

25 
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Required: 
Source  Field: 
Source  Table: 


False 

Outlinetlled 

CourseJournal 


ReadingListFiled 

AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
DisplayControl: 
Format: 

Ordinal  Position: 
Required: 
Source  Field: 
Source  Table: 


Yes/No 


False 

Fixed  Size 

General 

False 

Default 

Default 

106 

Yes/No 

26 

False 

ReadingListFiled 

CourseJournal 


Homeworkfiled 

AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
DisplayControl: 
Format: 

Ordinal  Position: 
Required: 
Source  Field: 
Source  Table: 


Yes/No 


False 

Fixed  Size 

General 

False 

Default 

Default 

106 

Yes/No 

27 

False 

Homeworkfiled 

CourseJournal 


Examsfiled 

AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 
ColumnOrder 
ColumnWidth: 
DisplayControl: 
Format: 

Ordinal  Position: 
Required: 
Source  Field: 
Source  Table: 


Yes/No 


False 

Fixed  Size 

General 

False 

Default 

Default 

106 

Yes/No 

28 

False 

Examsfiled 

CourseJournal 


Otherfiled 


Yes/No 


AllowZeroLength: 
Attributes: 
Collating  Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
DisplayControl: 
Format: 

Ordinal  Position: 
Required: 
Source  Field: 
Source  Table: 


False 

Fixed  Size 

General 

False 

Default 

Default 

106 

Yes/No 

29 

False 

Otherfiled 

CourseJournal 


Table  Indexes 
Name 
ID 


Clustered: 
Distinct  Count: 
Foreign: 
Ignore  Nulls: 


Number  of  Fields 
1 


False 
12 

False 
False 
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Name: 

JD 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

ID,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

12 

Foreign: 

False 

Ignore  Nulls: 

False 

Table:  CourseJournal 


Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

ID,  Ascending 

Table:  Curric 

Columns 

• 

Name 

Type 

CurricName 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

1 

ColumnWidth: 

5850 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

CurricName 

Source  Table: 

Curric 

CurricNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

CurricNumber 

Source  Table: 

Curric 

AcadAssoc 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth. 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

AcadAssoc 

Source  Table: 

Curric 

Table  Indexes 

Size 


60 


10 


Name 


Number  of  Fields 
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Table:  Curric 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

15 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

CurricNumber,  Ascending 

Table:  FacPref 


Name 

Type 

LastName 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

LastName 

Source  Table: 

FacPref 

CourseNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

CourseNumber 

Source  Table: 

FacPref 

Quarter 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

Quarter 

Source  Table: 

FacPref 

Size 


Columns 


20 


10 


Table:  FACULTY 

Columns 


Name 

emailaddress 

AllowZeroLength: 
Attributes: 


Type 
Text 


Size 


35 


False 
Variable  Length 
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Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

3765 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

emailaddress 

Source  Table: 

FACULTY 

FirstName 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

FirstName 

Source  Table: 

FACULTY 

LastName 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

LastName 

Source  Table: 

FACULTY 

Telephone 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

Telephone 

Source  Table: 

FACULTY 

OfficeNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWdth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

5 

Required: 

False 

Source  Field: 

OfficeNumber 

Source  Table: 

FACULTY 

ID 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

20 


20 


15 


10 
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Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

ID 

Source  Table: 

FACULTY 

CODE 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

CODE 

Source  Table: 

FACULTY 

Table  Indexes 

Name 

Number  of  Fields 

JD 

1 

Clustered: 

False 

Distinct  Count: 

82 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

JD 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

ID,  Ascending 

CODE 

1 

Clustered: 

False 

Distinct  Count: 

81 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

CODE 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

CODE,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

82 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

ID,  Ascending 

Table:  SOFInput 

Columns 

Name 

Type 

Code 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

Code 

Size 
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Source  Table: 

SOFInput 

JD 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

JD 

Source  Table: 

SOFInput 

CourseNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

CourseNumber 

Source  Table: 

SOFInput 

SegmentNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1755 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

SegmentNumber 

Source  Table: 

SOFInput 

SubSOFNumber 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

SubSOFNumber 

Source  Table: 

SOFInput 

SOFNumber 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

SOFNumber 

Source  Table: 

SOFInput 

CurricNum 

Number  (Long) 

AllowZeroLength: 

False 

10 


10 
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Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

CurricNum 

Source  Table: 

SOFInput 

HrsThisQtr 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes. 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

HrsThisQtr 

Source  Table: 

SOFInput 

QtrsComplete 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

10 

Required: 

False 

Source  Field: 

QtrsComplete 

Source  Table: 

SOFInput 

SOFQuestion_1 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1875 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

11 

Required: 

False 

Source  Field: 

SOFQuestion_1 

Source  Table: 

SOFInput 

SOFQuestion_2 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1875 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

12 

Required: 

False 

Source  Field: 

SOFQuestion_2 

Source  Table: 

SOFInput 
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SOFQuestion_3 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1935 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

13 

Required: 

False 

Source  Field: 

SOFQuestion_3 

Source  Table: 

SOFInput 

SOFQuestion_4 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1755 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

14 

Required: 

False 

Source  Field: 

SOFQuestion_4 

Source  Table: 

SOFInput 

SOFQuestion_5 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1695 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

15 

Required: 

False 

Source  Field: 

SOFQuestion_5 

Source  Table: 

SOFInput 

SOFQuestion_6 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1815 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

16 

Required: 

False 

Source  Field: 

SOFQuestion_6 

Source  Table: 

SOFInput 

SOFQuestion_7 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1740 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

17 

Required: 

False 

Source  Field: 

SOFQuestion_7 

Source  Table: 

SOFInput 
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SOFQuestion_8 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1635 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

18 

Required: 

False 

Source  Field: 

SOFQuestion_8 

Source  Table: 

SOFInput 

SOFQuestion_9 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1620 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

19 

Required: 

False 

Source  Field: 

SOFQuestion_9 

Source  Table: 

SOFInput 

SOFQuestion_10 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1815 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

20 

Required: 

False 

Source  Field: 

SOFQuestion_10 

Source  Table: 

SOFInput 

SOFQuestion_1 1 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWdth: 

1740 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

21 

Required: 

False 

Source  Field: 

SOFQuestion_1 1 

Source  Table: 

SOFInput 

SOFQuestion_12 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1650 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

22 

Required: 

False 

Source  Field: 

SOFQuestion_12 

Source  Table: 

SOFInput 
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SOFQuestion_13 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1740 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

23 

Required: 

False 

Source  Field: 

SOFQuestion_13 

Source  Table: 

SOFInput 

SOFQuestion_14 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1680 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

24 

Required: 

False 

Source  Field: 

SOFQuestion_14 

Source  Table: 

SOFInput 

SOFQuestion_15 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1725 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

25 

Required: 

False 

Source  Field: 

SOFQuestion_15 

Source  Table: 

SOFInput 

SOFQuestion_16 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1710 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

26 

Required: 

False 

Source  Field: 

SOFQuestion_16 

Source  Table: 

SOFInput 

SOFQuestion_17 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1725 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

27 

Required: 

False 

Source  Field: 

SOFQuestion_17 

Source  Table: 

SOFInput 
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SOFQuestion_18 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHiddert: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1695 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

28 

Required: 

False 

Source  Field: 

SOFQuestion_18 

Source  Table: 

SOFInput 

SOFQuestion_19 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1650 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

29 

Required: 

False 

Source  Field: 

SOFQuestion_19 

Source  Table: 

SOFInput 

SOFQuestion_20 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

1920 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

30 

Required: 

False 

Source  Field: 

SOFQuestion_20 

Source  Table: 

SOFInput 

SOFcomments 

Memo 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

4800 

Ordinal  Position: 

31 

Required: 

False 

Source  Field: 

SOFcomments 

Source  Table: 

SOFInput 

SOF_ID_FK5 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

DisplayControl: 

Text  Box 

Ordinal  Position: 

32 

Required: 

False 

Source  Field: 

SOF_ID_FK5 

Source  Table: 

SOFInput 
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Table  Indexes 

Name 

Number  of  Fields 

JD 

1 

Clustered: 

False 

Distinct  Count: 

53 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

JD 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

JD,  Ascending 

Code 

1 

Clustered: 

False 

Distinct  Count: 

6 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

Code 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

Code,  Ascending 

Table:  TeachingAssignment 

Columns 

Name 

Type 

Code 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

Code 

Source  Table: 

TeachingAssignment 

JD 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

JD 

Source  Table: 

TeachingAssignment 

Segments 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

Segments 

Source  Table: 

TeachingAssig  nment 

CourseNumber 

Text 

Size 


50 


50 


165 


AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

CourseNumber 

Source  Table: 

TeachingAssignment 

Yea  rOffered 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

5 

Required: 

False 

Source  Field: 

YearOffered 

Source  Table: 

TeachingAssignment 

Quarter 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

Quarter 

Source  Table: 

TeachingAssignment 

CreditHours 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWdth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

CreditHours 

Source  Table: 

TeachingAssignment 

Enrollment 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

10 


50 


50 


Table:  TeachingAssignment 


ColumnHidden: 

False: 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

Enrollment 

Source  Table: 

TeachingAssignment 
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CoordWith 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

CoordWith 

Source  Table: 

TeachingAssignment 

Table  Indexes 

Name 

Number  of  Fields 

JD 

1 

Clustered: 

False 

Distinct  Count: 

78 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

JD 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

JD,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

78 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

JD,  Ascending 

50 


Table:  Text  Book 

Name 
Author 


Title 


Type 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

Author 

Source  Table: 

TextBook 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

Title 

Source  Table: 

TextBook 

Size 


Columns 


50 


75 
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ISBN 


Text 


50 


AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

ISBN 

Source  Table: 

TextBook 

CODE 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

CODE 

Source  Table: 

TextBook 

CourseNumber 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

CourseNumber 

Source  Table: 

TextBook 

Quarter 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

Quarter 

Source  Table: 

TextBook 

Year 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

Year 

Source  Table: 

TextBook 

Edition 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

Text 


50 


Text 


Text 


50 


Text 


50 


Text 
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Table: 


ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

Edition 

Source  Table: 

TextBook 

YearofBook 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

10 

Required: 

False 

Source  Field: 

YearofBook 

Source  Table: 

TextBook 

Publisher 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

11 

Required: 

False 

Source  Field: 

Publisher 

Source  Table: 

TextBook 

RequiredNum 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

12 

Required: 

False 

Source  Field: 

RequiredNum 

Source  Table: 

TextBook 

AnticipatedEnrollment 

Number  (Integer) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size 

TextBook 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Decimal  Places: 

Auto 

Default  Value: 

0 

DisplayControl: 

Text  Box 

Ordinal  Position: 

13 

Required: 

False 

Source  Field: 

AnticipatedEnrollment 
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Source  Table: 

TextBook 

Segments 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order. 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

14 

Required: 

False 

Source  Field: 

Segments 

Source  Table: 

TextBook 

ID 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

15 

Required: 

False 

Source  Field: 

ID 

Source  Table: 

TextBook 

Table  Indexes 

Name 

Number  of  Fields 

CODE 

1 

Clustered: 

False 

Distinct  Count: 

9 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

CODE 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

CODE,  Ascending 

ID 

1 

Clustered: 

False 

Distinct  Count: 

16 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

ID 

Primary: 

False 

Required: 

False 

Unique: 

True 

Fields: 

ID,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

16 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

ID,  Ascending 

RequiredNum 

1 

Clustered: 

False 

Distinct  Count: 

14 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

RequiredNum 

Primary: 

False 

Required: 

False 
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Unique: 
Fields: 


False 

RequiredNum,  Ascending 


Table:  ThesisFacAssessment 


Columns 

Name 

Type 

FacName 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

1 

Required: 

False 

Source  Field: 

FacName 

Source  Table: 

ThesisFacAssessment 

Role 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

2 

Required: 

False 

Source  Field: 

Role 

Source  Table: 

ThesisFacAssessment 

Curric 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

3 

Required: 

False 

Source  Field: 

Curric 

Source  Table: 

ThesisFacAssessment 

OtherCurric 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

4 

Required: 

False 

Source  Field: 

OtherCurric 

Source  Table: 

ThesisFacAssessment 

Service 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Size 


50 


50 


50 


50 


50 
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Ordinal  Position: 

5 

Required: 

False 

Source  Field: 

Service 

Source  Table: 

ThesisFacAssessment 

GradDate 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

6 

Required: 

False 

Source  Field: 

GradDate 

Source  Table: 

ThesisFacAssessment 

Questionl 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

7 

Required: 

False 

Source  Field: 

Questionl 

Source  Table: 

ThesisFacAssessment 

Question2 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

8 

Required: 

False 

Source  Field: 

Question2 

Source  Table: 

ThesisFacAssessment 

Question3 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

9 

Required: 

False 

Source  Field: 

Question3 

Source  Table: 

ThesisFacAssessment 

Question4 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

10 

Required: 

False 

Source  Field: 

Question4 

Source  Table: 

ThesisFacAssessment 

50 


50 


50 


50 


50 
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Question5 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

11 

Required: 

False 

Source  Field: 

Question5 

Source  Table: 

ThesisFacAssessment 

Question6 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

12 

Required: 

False 

Source  Field: 

Question6 

Source  Table: 

ThesisFacAssessment 

Question7 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

13 

Required: 

False 

Source  Field: 

Question7 

Source  Table: 

ThesisFacAssessment 

Question8 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

14 

Required: 

False 

Source  Field: 

Question8 

Source  Table: 

ThesisFacAssessment 

Question9 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

15 

Required: 

False 

Source  Field: 

Question9 

Source  Table: 

ThesisFacAssessment 

QuestionIO 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

50 


50 


50 


50 


50 


50 
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ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

16 

Required: 

False 

Source  Field: 

Question  10 

Source  Table: 

ThesisFacAssessment 

Question  11 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

17 

Required: 

False 

Source  Field: 

Question11 

Source  Table: 

ThesisFacAssessment 

Date 

Text 

AllowZeroLength: 

False 

Attributes: 

Variable  Length 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

DisplayControl: 

Text  Box 

Ordinal  Position: 

18 

Required: 

False 

Source  Field: 

Date 

Source  Table: 

ThesisFacAssessment 

JD 

Number  (Long) 

AllowZeroLength: 

False 

Attributes: 

Fixed  Size,  Auto-Increment 

Collating  Order: 

General 

ColumnHidden: 

False 

ColumnOrder: 

Default 

ColumnWidth: 

Default 

Ordinal  Position: 

19 

Required: 

False 

Source  Field: 

JD 

Source  Table: 

ThesisFacAssessment 

50 


50 
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Table  Indexes 

Name 

Number  of  Fields 

JD 

1 

Clustered: 

False 

Distinct  Count: 

2 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

JD 

Primary: 

False 

Required: 

False 

Unique: 

False 

Fields: 

JD,  Ascending 

PrimaryKey 

1 

Clustered: 

False 

Distinct  Count: 

2 

Foreign: 

False 

Ignore  Nulls: 

False 

Name: 

PrimaryKey 

Primary: 

True 

Required: 

True 

Unique: 

True 

Fields: 

JD,  Ascending 

[75 


176 


INITIAL  DISTRIBUTION  LIST 

No.  Copies 

1.  Defense  Technical  Information  Center  2 
8725  John  J.  Kingman  Rd.,  Ste  0944 

Ft.  Belvoir,  VA  22060-6218 

2.  Dudley  Knox  Library  2 
Naval  Postgraduate  School 

411  DyerRd. 

Monterey,  CA  93943-5101 

3.  Professor  Suresh  Sridhar  (Code  SM/Sr)  1 
Naval  Postgraduate  School 

Systems  Management  Department 
Monterey,  CA  93943-5000 

4.  Professor  Hemnant  K.  Bhargava  (Code  SM/Bh)  1 
Naval  Postgraduate  School 

Systems  Management  Department 
Monterey,  CA  93943-5000 

5.  Professor  Carl  Jones  (Code  SM/Js)  1 
Naval  Postgraduate  School 

Systems  Management  Department 
Monterey,  CA  93943-5000 

6.  LCDR  Dale  Courtney  (Code  05C)  1 
Naval  Postgraduate  School 

Monterey,  CA  93943 

7.  MAJ  Robert  H.  Lunn  2 
342  Ardennes  Circle 

Seaside,  CA  93955 

8.  CPT  Edward  D.  Loewen  2 
5735  Rocksbury  Lane 

Dale  City,  VA  22193 

9.  MG(R)DeWittT.  Irby,  Jr.  1 
843  South  Bramble  Way 

Anaheim,  CA  98202 


177 


10.  BG(R)Orlin  L.Mullen 
120  Kir-wan' s  Landing  Lane 
Chester,  MD  21619 

1 1 .  LTC(P)  Richard  J.  Langhorst 
5207  Gainsborough  Dr 
Fairfax,  VA  22032 


178 


JM  OX  LIBRARY 

2$>  Vq**D}L*IB  SCHOOL 


3943-5101 


DUDLEY  KNOX  LIBRARY 


3  2768  00339512  0 


